On Mon, Apr 16, 2007 at 11:00:01PM +0100, Alan Cox wrote: > > don't actually have to care --- if loading an invalid profile can bring down > > the system, then that's no worse than an arbitrary module that crashes the > > machine. Not sure if there will ever be user loadable profiles; at least at > > that point we had to care. > > CAP_SYS_RAWIO is needed to do arbitary patching/loading in the capability > model so if you are using lesser capabilities it is a (minor) capability > rise but not a big problem, just ugly and wanting a fix > > > > > + /* > > > > + * Replacement needs to allocate a new aa_task_context for each > > > > + * task confined by old_profile. To do this the profile locks > > > > + * are only held when the actual switch is done per task. While > > > > + * looping to allocate a new aa_task_context the old_task list > > > > + * may get shorter if tasks exit/change their profile but will > > > > + * not get longer as new task will not use old_profile detecting > > > > + * that is stale. > > > > + */ > > > > + do { > > > > + new_cxt = aa_alloc_task_context(GFP_KERNEL | __GFP_NOFAIL); > > > > > > NOFAIL is usually a bad sign. It should be only used if there is no > > > alternative. > > > > At this point there is no secure alternative to allocating a task context --- > > except killing the task, maybe. > > Can you count the number needed, preallocate them and then when you know > for sure either succeed or fail the operation as a whole ? No, to be accurate the count would have to be made with the profile lock held, which would then need to be released so as not to use GFP_ATOMIC for the allocations. An iterative approach could be taken where we do something like repeat: lock profile count if preallocated < count unlock profile if (! allocate count - preallocated) Fail goto repeat do replacement
Attachment:
pgpSzKYLTH3bJ.pgp
Description: PGP signature
- References:
- [AppArmor 00/41] AppArmor security module overview
- From: [email protected]
- [AppArmor 39/41] AppArmor: Profile loading and manipulation, pathname matching
- From: [email protected]
- Re: [AppArmor 39/41] AppArmor: Profile loading and manipulation, pathname matching
- From: Andi Kleen <[email protected]>
- Re: [AppArmor 39/41] AppArmor: Profile loading and manipulation, pathname matching
- From: Andreas Gruenbacher <[email protected]>
- Re: [AppArmor 39/41] AppArmor: Profile loading and manipulation, pathname matching
- From: Alan Cox <[email protected]>
- [AppArmor 00/41] AppArmor security module overview
- Prev by Date: Re: bug in tcp?
- Next by Date: Re: [patch -mm] i386: use pte_update_defer in ptep_test_and_clear_{dirty,young}
- Previous by thread: Re: [AppArmor 39/41] AppArmor: Profile loading and manipulation, pathname matching
- Next by thread: [AppArmor 34/41] Enable LSM hooks to distinguish operations on file descriptors from operations on pathnames.
- Index(es):