lkml.org 
[lkml]   [2007]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [AppArmor 39/41] AppArmor: Profile loading and manipulation, pathname matching
> 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 ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-04-16 23:59    [W:0.623 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site