linux-kernel - Re: [AppArmor 39/45] 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]

Date:	Sat, 16 Jun 2007 09:24:34 -0700
From:	Greg KH <greg@...ah.com>
To:	david@...g.hm
Cc:	Crispin Cowan <crispin@...ell.com>, Pavel Machek <pavel@....cz>,
	Andreas Gruenbacher <agruen@...e.de>,
	Stephen Smalley <sds@...ho.nsa.gov>, jjohansen@...e.de,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation,
	pathname matching

On Sat, Jun 16, 2007 at 01:09:06AM -0700, david@...g.hm wrote:
>  On Fri, 15 Jun 2007, Greg KH wrote:
> 
> >>> Usually you don't do that by doing a 'mv' otherwise you are almost
> >>> guaranteed stale and mixed up content for some period of time, not to
> >>> mention the issues surrounding paths that might be messed up.
> >>
> >>  on the contrary, useing 'mv' is by far the cleanest way to do this.
> >>
> >>  mv htdocs htdocs.old;mv htdocs.new htdocs
> >>
> >>  this makes two atomic changes to the filesystem, but can generate 
> >> thousands
> >>  to millions of permission changes as a result.
> >
> > I agree, and yet, somehow, SELinux today handles this just fine, right?
> > :)
> 
>  no it doesn't, SELinux as-is should take no action when the above command is 
>  run, but SELinux implementing path-based permissions will have to relabel 
>  every file or directory in both trees.

Agreed.

> > Let's worry about speed issues later on when a working implementation is
> > produced, I'm still looking for the logical reason a system like this
> > can not work properly based on the expected AA interface to users.
> 
>  if you are willing to live with the race conditions from the slow 
>  (re)labeling and write the software to scan the entire system to figure out 
>  the right policies (and then use inotify to watch the entire system for 
>  changes and (re)label the appropriate files) and accept that you can't get 
>  any granular security for filesystems that don't nativly support it you 
>  could make SELinux behave like AA.

You make it sound like such a pretty picture :)

Anyway, I don't think there are "race conditions", just a bit of a delay
at times for situations that are not common or "normal operations".  And
as I think the speed issues can be drasticly reduced, I don't think
that's a really big deal just yet.  I'm trying to determine if there's
any logical reason why we can't do this and have yet to see proof of
that.

>  but why should they be required to? are you saying that the LSM hooks are 
>  not a valid API and should be removed with all future security modules being 
>  based on SELinux?

Woah, that's a huge logical jump that I am not willing to make at this
point in time.

The reason I am proposing this for AA is due to the impeadance between
the AA model and how the kernel internally works.  A number of core
kernel  VFS developers have objected to the AA code and changes because
of this problem and me and Pavel are here working to try to resolve this
in a way that is acceptable to everyone involved (kernel developers and
AA developers and AA end users.)

I'll leave the whole "LSM should be just replaced with SELinux"
discussion for later, as it is not relevant to this current topic at
all.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/