| Main Archive Page > Month Archives > linux-kernel archives |
Re: [AppArmor 39/41] AppArmor: Profile loading and manipulation, pathname matching
From: John Johansen <jjohansen_at_nospam>Date: Mon Apr 16 2007 - 22:11:44 GMT
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
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
-
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html