linux-kernel - Re: [AppArmor 39/41] AppArmor: Profile loading and manipulation, pathname matching

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070416221143.GA1143@suse.de>
Date:	Mon, 16 Apr 2007 15:11:44 -0700
From:	John Johansen <jjohansen@...e.de>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Andreas Gruenbacher <agruen@...e.de>,
	Andi Kleen <andi@...stfloor.org>, jjohansen@...e.de,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, chrisw@...s-sol.org
Subject: Re: [AppArmor 39/41] AppArmor: Profile loading and manipulation, pathname matching

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

Content of type "application/pgp-signature" skipped