Using fs views to isolate untrusted processes: I need an assistant architect in the USA for Phase I of a DARPA funded linux kernel project

Using fs views to isolate untrusted processes: I need an assistant architect in the USA for Phase I of a DARPA funded linux kernel project

[Hans Reiser]

You can think of this as chroot on steroids.  The idea is to use the 
concept of views, in which one specifies a description of what in the fs 
should be visible in the view, and extend them to become "tracing views" 
which automate the creation of "viewprints", which contain what a 
process attempted to access during some period when it was being 
supervised, and then use these viewprints to conveniently specify a view 
that defines what the process should be allowed to access.  It is not 
that this is better than chroot, it is that it is to be made much less 
human work to use than chroot, as chroot is used much too rarely in 
practice.

Another concept of the proposal is that of process oriented security, as 
opposed to the object oriented security usual to filesystems.  These 
viewprints will be associated with the executables of the processes 
being isolated, not with the files, and this is academically amusing as 
a distinction I think.

You can find details of our proposal at 
www.namesys.com/blackbox_security.html.  You have to be able to perform 
the work in the US (a government requirement for this contract), which 
means that I cannot use my current Russian staff (the US State 
department is making it hard to get visas these days).

If you have an interest in filesystems, views, security, and the linux 
kernel, you might find it fun.  It should be a nice opportunity for an 
ambitious young software architect, and I like to think that the people 
who work for me learn a bit.  The infrastructure you will help spec out 
will be useful for lots of other purposes besides security (version 
control, search refinement, etc.)  The work will be GPL'd, etc.

If you would like to know more about namesys and reiser4, you can look 
at www.namesys.com

Please email me directly if it interests you rather than just responding 
to the thread.

Hans

Re: Using fs views to isolate untrusted processes: I need an assistant architect in the USA for Phase I of a DARPA funded linux kernel project

[Christian Mayrhuber]

On Monday 02 August 2004 03:20, Hans Reiser wrote:
> You can think of this as chroot on steroids.  The idea is to use the
> concept of views, in which one specifies a description of what in the fs
> should be visible in the view, and extend them to become "tracing views"
> which automate the creation of "viewprints", which contain what a
> process attempted to access during some period when it was being
> supervised, and then use these viewprints to conveniently specify a view
> that defines what the process should be allowed to access.  It is not
> that this is better than chroot, it is that it is to be made much less
> human work to use than chroot, as chroot is used much too rarely in
> practice.
>
> Another concept of the proposal is that of process oriented security, as
> opposed to the object oriented security usual to filesystems.  These
> viewprints will be associated with the executables of the processes
> being isolated, not with the files, and this is academically amusing as
> a distinction I think.

Linux VServer might be a project that already tries to accomplish this task.
http://linux-vserver.org/
It's working well on 2.4.x, but it still has some security weaknesses.
The development is focussing on the 2.6 kernel series.
They are simulating a chroot on steroids by jailing the vservers in a
directory marked by:
  chmod 000 vservers
  chattr +t vservers (no other attributes are allowed)
It supports all linux filesystems, that support attributes. Reiserfs needs to
be mounted with "attrs" to be safe.
Herbert Poetzl <herbert@13thfloor.at> is the main developer.

-- 
lg, Chris

Re: Using fs views to isolate untrusted processes: I need an assistant architect in the USA for Phase I of a DARPA funded linux kernel project

[Hubert Chan]

>>>>> "Christian" == Christian Mayrhuber <christian.mayrhuber@gmx.net> writes:

Christian> Linux VServer might be a project that already tries to
Christian> accomplish this task.

After poking around the linux-veserver.org page, it sounds like Linux
VServer is completely different from what Hans/Namesys is trying to do.
Linux VServer still uses chroot.  From what I understand about views,
you don't need to set up a chroot; applications run under the same
filesystem as everything else.  You just need to, for example, say that
apache is allowed to read from /etc/apache/*, /var/www, /usr/lib, etc.,
and is allowed to write to /var/log/apache/*.  Then, even though apache
is running under the same filesystem, it won't even be able to see, say
/etc/passwd.

-- 
Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.

Re: Using fs views to isolate untrusted processes: I need an assistant architect in the USA for Phase I of a DARPA funded linux kernel project

[Hans Reiser]

Hubert Chan wrote:

>>>>>>"Christian" == Christian Mayrhuber <christian.mayrhuber@gmx.net> writes:
>>>>>>            
>>>>>>
>
>Christian> Linux VServer might be a project that already tries to
>Christian> accomplish this task.
>
>After poking around the linux-veserver.org page, it sounds like Linux
>VServer is completely different from what Hans/Namesys is trying to do.
>Linux VServer still uses chroot.  From what I understand about views,
>you don't need to set up a chroot; applications run under the same
>filesystem as everything else.  You just need to, for example, say that
>apache is allowed to read from /etc/apache/*, /var/www, /usr/lib, etc.,
>and is allowed to write to /var/log/apache/*.  Then, even though apache
>is running under the same filesystem, it won't even be able to see, say
>/etc/passwd.
>
>  
>
Thanks for being more eloquent than what I was going to say.;-)

Re: Using fs views to isolate untrusted processes: I need an assistant architect in the USA for Phase I of a DARPA funded linux kernel project

[Christian Mayrhuber]

On Monday 02 August 2004 19:29, Hubert Chan wrote:
> >>>>> "Christian" == Christian Mayrhuber <christian.mayrhuber@gmx.net>
> >>>>> writes:
>
> Christian> Linux VServer might be a project that already tries to
> Christian> accomplish this task.
>
> After poking around the linux-veserver.org page, it sounds like Linux
> VServer is completely different from what Hans/Namesys is trying to do.
> Linux VServer still uses chroot.  From what I understand about views,
> you don't need to set up a chroot; applications run under the same
> filesystem as everything else.  You just need to, for example, say that
> apache is allowed to read from /etc/apache/*, /var/www, /usr/lib, etc.,
> and is allowed to write to /var/log/apache/*.  Then, even though apache
> is running under the same filesystem, it won't even be able to see, say
> /etc/passwd.
Yes, you are right, after reading Hans writeup on the homepage it's clear to 
me. Views will be definitely very handy. Process Oriented Security seems to 
be a rather complicated task to administer - it reads like tripwire 
configuration.

The vserver project has similiar goals:
 - ease administration
 - higher security

chroot() + a marker is still used, because there is nothing better available 
today ...
Process separation is accomplished by attaching a context number to every 
process. Processes with a higher context number than 1 are jailed in their 
root directory. The network interfaces, process RAM, CPU and disk quota usage 
is also bound to the same number.
You can give a "view" to the world outside the chroot() jail by using
"mount --bind" in the pre-start phase of the vserver.

The views and process oriented security concepts seem to be orthogonal to 
linux vserver.

-- 
lg, Chris

Re: Using fs views to isolate untrusted processes: I need an assistant architect in the USA for Phase I of a DARPA funded linux kernel project

[Hans Reiser]

Christian Mayrhuber wrote:

>On Monday 02 August 2004 19:29, Hubert Chan wrote:
>  
>
>>>>>>>"Christian" == Christian Mayrhuber <christian.mayrhuber@gmx.net>
>>>>>>>writes:
>>>>>>>              
>>>>>>>
>>Christian> Linux VServer might be a project that already tries to
>>Christian> accomplish this task.
>>
>>After poking around the linux-veserver.org page, it sounds like Linux
>>VServer is completely different from what Hans/Namesys is trying to do.
>>Linux VServer still uses chroot.  From what I understand about views,
>>you don't need to set up a chroot; applications run under the same
>>filesystem as everything else.  You just need to, for example, say that
>>apache is allowed to read from /etc/apache/*, /var/www, /usr/lib, etc.,
>>and is allowed to write to /var/log/apache/*.  Then, even though apache
>>is running under the same filesystem, it won't even be able to see, say
>>/etc/passwd.
>>    
>>
>Yes, you are right, after reading Hans writeup on the homepage it's clear to 
>me. Views will be definitely very handy. Process Oriented Security seems to 
>be a rather complicated task to administer - it reads like tripwire 
>configuration.
>
>The vserver project has similiar goals:
> - ease administration
> - higher security
>
>chroot() + a marker is still used, because there is nothing better available 
>today ...
>Process separation is accomplished by attaching a context number to every 
>process. Processes with a higher context number than 1 are jailed in their 
>root directory. The network interfaces, process RAM, CPU and disk quota usage 
>is also bound to the same number.
>You can give a "view" to the world outside the chroot() jail by using
>"mount --bind" in the pre-start phase of the vserver.
>
>The views and process oriented security concepts seem to be orthogonal to 
>linux vserver.
>
>  
>
Perhaps we will be a tool verver will find useful.

Re: Using fs views to isolate untrusted processes: I need an assistant architect in the USA for Phase I of a DARPA funded linux kernel project

[David Greaves]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hubert Chan wrote:
|>>>>>"Christian" == Christian Mayrhuber <christian.mayrhuber@gmx.net>
writes:
|
|
| Christian> Linux VServer might be a project that already tries to
| Christian> accomplish this task.
|
| After poking around the linux-veserver.org page, it sounds like Linux
| VServer is completely different from what Hans/Namesys is trying to do.
| Linux VServer still uses chroot.  From what I understand about views,
| you don't need to set up a chroot; applications run under the same
| filesystem as everything else.  You just need to, for example, say that
| apache is allowed to read from /etc/apache/*, /var/www, /usr/lib, etc.,
| and is allowed to write to /var/log/apache/*.  Then, even though apache
| is running under the same filesystem, it won't even be able to see, say
| /etc/passwd.
|

It sounds like running exe's setgid (or addgid?) and then having acls.
But then the acls are not tied to the file objects, more appended to the
file acl list by 'pattern' according to the exe.

Acls at a distance :)

David
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBDrvU8LvjTle4P1gRAkt1AJsFhmZI6OP4KRxY+JnPnq6lhhozLACePwl7
s4Zl5NO9YcTLYcKBxg1g9Qc=
=ZU/S
-----END PGP SIGNATURE-----

Re: Using fs views to isolate untrusted processes: I need an assistant architect in the USA for Phase I of a DARPA funded linux kernel project

[Hubert Chan]

>>>>> "David" == David Greaves <david@dgreaves.com> writes:

David> It sounds like running exe's setgid (or addgid?) and then having acls.
David> But then the acls are not tied to the file objects, more appended
David> to the file acl list by 'pattern' according to the exe.

Possibly.  But, from my understanding of views, apache would not even
be able to see that /etc/passwd exists -- it is not just limited to not
being able to read it.  I don't think you can do that with acls, and
still allow apache to see some entries in /etc.

It also seems much easier to administer, since the permissions are tied
to the executable, rather than being tied to the file object.  (Say I
want to see what files apache can read as part of a security audit --
with acls, I would have to do a search over the whole filesystem.)

-- 
Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.

Re: Using fs views to isolate untrusted processes: I need an assistant architect in the USA for Phase I of a DARPA funded linux kernel project

[Matt Stegman]

It sounds closer to trustees than ACLs - permissions applied higher in the
tree apply to lower objects by default, unless inheritance is explicitly
denied.  Except this is done per process, not per user/group.  Presumably,
other processes would not be able to see what a process' view is).

Now, I'd love to see trustees implemented in reiser4 (warning: moving
off-topic now).  Are any plans in the works to implement POSIX ACLs or
other permission schemes more flexible than your regular UNIX permissions?
I've used trustees with Netware, and I believe they're quite superior to
ACLs.  I remember Hans' rant against EAs (aka xattrs) but I don't think he
ever said he hated ACLs as well.  And with the metas/plugin/permission
file it looks like some groundwork exists for ACLs/trustees/whatever.

-- 
Matt Stegman


On Mon, 2 Aug 2004, Hubert Chan wrote:

> >>>>> "David" == David Greaves <david@dgreaves.com> writes:
>
> David> It sounds like running exe's setgid (or addgid?) and then having acls.
> David> But then the acls are not tied to the file objects, more appended
> David> to the file acl list by 'pattern' according to the exe.
>
> Possibly.  But, from my understanding of views, apache would not even
> be able to see that /etc/passwd exists -- it is not just limited to not
> being able to read it.  I don't think you can do that with acls, and
> still allow apache to see some entries in /etc.
>
> It also seems much easier to administer, since the permissions are tied
> to the executable, rather than being tied to the file object.  (Say I
> want to see what files apache can read as part of a security audit --
> with acls, I would have to do a search over the whole filesystem.)

Re: Using fs views to isolate untrusted processes: I need an assistant architect in the USA for Phase I of a DARPA funded linux kernel project

[David Greaves]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hubert Chan wrote:
|>>>>>"David" == David Greaves <david@dgreaves.com> writes:
|
|
| David> It sounds like running exe's setgid (or addgid?) and then
having acls.
| David> But then the acls are not tied to the file objects, more appended
| David> to the file acl list by 'pattern' according to the exe.
|
| Possibly.  But, from my understanding of views, apache would not even
| be able to see that /etc/passwd exists -- it is not just limited to not
| being able to read it.  I don't think you can do that with acls, and
| still allow apache to see some entries in /etc.

Given that you are extending the semantics then this is resolvable.

| It also seems much easier to administer, since the permissions are tied
| to the executable, rather than being tied to the file object.  (Say I
| want to see what files apache can read as part of a security audit --
| with acls, I would have to do a search over the whole filesystem.)

Yes, I understand - and agree.
Essentially there is an ACL set that lives with the exe.

I would expect this ACL set to be be normally deny based rather than
grant based?
Or could I grant write permission in the ACL set and override readonly
on the file ACL? That sounds unpleasantly interesting ;)

It seems to makes sense therefore to filter your audit based on the ACL
set and then you have to walk that tree to determine which file ACLs
grant what.

This solves the problem above - first check is the exe ACL set which
only has /etc/apache/* and so denies the existence of /etc/passwd

Note that /etc/ap* is essentially improving the granularity of +r on a
directory.

David
P.S. At this level of conversation, ACL may not mean posix acl - maybe
it should be access control mechanism for now - ACLs being a reasonable
first approximation.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBD00d8LvjTle4P1gRApycAJ0ZwAoGHV5GhL7R1dwU1gMhPC4AqgCfYs/3
jap29oSk8sKdhI2nd1bTvoo=
=25CC
-----END PGP SIGNATURE-----

Re: Using fs views to isolate untrusted processes: I need an assistant architect in the USA for Phase I of a DARPA funded linux kernel project

[Pierre Etchemaite]

Le Mon, 02 Aug 2004 20:04:34 -0400, Hubert Chan <hubert@uhoreg.ca> a écrit :

> Possibly.  But, from my understanding of views, apache would not even
> be able to see that /etc/passwd exists -- it is not just limited to not
> being able to read it.  I don't think you can do that with acls, and
> still allow apache to see some entries in /etc.

Vserver has been mentionned, but now I cannot help but think about grsec
patch (http://www.grsecurity.net/), and possibly other similar works.
There's interesting papers on this site on how they improved the performance
of their rules system with v2.0.

Implementing file access at filesystem level looks more natural, on the
other hand implementing it as a separate patch has advantages (filesystem
independancy, unification of rules for both files and non-files objects
-like processes-)...

Re: Using fs views to isolate untrusted processes: I need an assistant architect in the USA for Phase I of a DARPA funded linux kernel project

[James Courtier-Dutton]

Hans Reiser wrote:
> You can think of this as chroot on steroids.  The idea is to use the 
> concept of views, in which one specifies a description of what in the fs 
> should be visible in the view, and extend them to become "tracing views" 
> which automate the creation of "viewprints", which contain what a 
> process attempted to access during some period when it was being 
> supervised, and then use these viewprints to conveniently specify a view 
> that defines what the process should be allowed to access.  It is not 
> that this is better than chroot, it is that it is to be made much less 
> human work to use than chroot, as chroot is used much too rarely in 
> practice.
> 
> Another concept of the proposal is that of process oriented security, as 
> opposed to the object oriented security usual to filesystems.  These 
> viewprints will be associated with the executables of the processes 
> being isolated, not with the files, and this is academically amusing as 
> a distinction I think.
> 
> You can find details of our proposal at 
> www.namesys.com/blackbox_security.html.  You have to be able to perform 
> the work in the US (a government requirement for this contract), which 
> means that I cannot use my current Russian staff (the US State 
> department is making it hard to get visas these days).
> 
> If you have an interest in filesystems, views, security, and the linux 
> kernel, you might find it fun.  It should be a nice opportunity for an 
> ambitious young software architect, and I like to think that the people 
> who work for me learn a bit.  The infrastructure you will help spec out 
> will be useful for lots of other purposes besides security (version 
> control, search refinement, etc.)  The work will be GPL'd, etc.
> 
> If you would like to know more about namesys and reiser4, you can look 
> at www.namesys.com
> 
> Please email me directly if it interests you rather than just responding 
> to the thread.
> 
> Hans
> 
> 

I am based in the UK so I cannot help directly. Unless the UK is close 
enought to the USA in this matter.

As a security feature, providing a restriction so that an application 
cannot execute any code in any files it created, could go a long way to 
reducing exploits.

E.g.
1) Web application has a buffer overflow bug
2) cracker uses the exploit to create a file, with exploit code in it, 
3) cracker then executes the exploit code.

If stage (3) could be blocked, for a particular application and all of 
it's child processes, web servers would be slightly more secure.
The "buffer overflow bug" could still be exploited, but it would be much 
more difficult.

If this was also combined with "fs views", one could ensure that the web 
application only had access to programs in /usr/bin that it actually 
needs to do it's job. E.g. If the web app does not have access to any 
file transfer tools in /usr/bin, then the cracker cannot create an 
executable, the cracker could not then download root kits so easily.

I might have missed it, but I have not seen features in linux yet, that 
prevent a user from setting the "execute" bit on files that they own.

James

Re: Using fs views to isolate untrusted processes: I need an assistant architect in the USA for Phase I of a DARPA funded linux kernel project

[Hans Reiser]

James Courtier-Dutton wrote:

> Hans Reiser wrote:
>
>> You can think of this as chroot on steroids.  The idea is to use the 
>> concept of views, in which one specifies a description of what in the 
>> fs should be visible in the view, and extend them to become "tracing 
>> views" which automate the creation of "viewprints", which contain 
>> what a process attempted to access during some period when it was 
>> being supervised, and then use these viewprints to conveniently 
>> specify a view that defines what the process should be allowed to 
>> access.  It is not that this is better than chroot, it is that it is 
>> to be made much less human work to use than chroot, as chroot is used 
>> much too rarely in practice.
>>
>> Another concept of the proposal is that of process oriented security, 
>> as opposed to the object oriented security usual to filesystems.  
>> These viewprints will be associated with the executables of the 
>> processes being isolated, not with the files, and this is 
>> academically amusing as a distinction I think.
>>
>> You can find details of our proposal at 
>> www.namesys.com/blackbox_security.html.  You have to be able to 
>> perform the work in the US (a government requirement for this 
>> contract), which means that I cannot use my current Russian staff 
>> (the US State department is making it hard to get visas these days).
>>
>> If you have an interest in filesystems, views, security, and the 
>> linux kernel, you might find it fun.  It should be a nice opportunity 
>> for an ambitious young software architect, and I like to think that 
>> the people who work for me learn a bit.  The infrastructure you will 
>> help spec out will be useful for lots of other purposes besides 
>> security (version control, search refinement, etc.)  The work will be 
>> GPL'd, etc.
>>
>> If you would like to know more about namesys and reiser4, you can 
>> look at www.namesys.com
>>
>> Please email me directly if it interests you rather than just 
>> responding to the thread.
>>
>> Hans
>>
>>
>
> I am based in the UK so I cannot help directly. Unless the UK is close 
> enought to the USA in this matter.
>
> As a security feature, providing a restriction so that an application 
> cannot execute any code in any files it created, could go a long way 
> to reducing exploits.
>
> E.g.
> 1) Web application has a buffer overflow bug
> 2) cracker uses the exploit to create a file, with exploit code in it, 
> 3) cracker then executes the exploit code.
>
> If stage (3) could be blocked, for a particular application and all of 
> it's child processes, web servers would be slightly more secure.
> The "buffer overflow bug" could still be exploited, but it would be 
> much more difficult.
>
> If this was also combined with "fs views", one could ensure that the 
> web application only had access to programs in /usr/bin that it 
> actually needs to do it's job. E.g. If the web app does not have 
> access to any file transfer tools in /usr/bin, then the cracker cannot 
> create an executable, the cracker could not then download root kits so 
> easily.
>
> I might have missed it, but I have not seen features in linux yet, 
> that prevent a user from setting the "execute" bit on files that they 
> own.
>
> James
>
>
Hmm.  Yes, views should allow masking permissions.

Re: Using fs views to isolate untrusted processes: I need an assistant architect in the USA for Phase I of a DARPA funded linux kernel project

[Rik van Riel]

On Sun, 1 Aug 2004, Hans Reiser wrote:

> You can think of this as chroot on steroids.

Sounds like what you want is pretty much the namespace stuff
that has been in the kernel since the early 2.4 days.

No need to replicate VFS functionality inside the filesystem.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: Using fs views to isolate untrusted processes: I need an assistant architect in the USA for Phase I of a DARPA funded linux kernel project

[Tim Hockin]

On Wed, Aug 25, 2004 at 04:25:24PM -0400, Rik van Riel wrote:
> > You can think of this as chroot on steroids.
> 
> Sounds like what you want is pretty much the namespace stuff
> that has been in the kernel since the early 2.4 days.
> 
> No need to replicate VFS functionality inside the filesystem.

When I was at Sun, we talked a lot about this.  Mike, does Sun have any
iterest in this?

We found a lot of shortcomings in implementing various namespace-ish
things.

Re: Using fs views to isolate untrusted processes: I need an assistant architect in the USA for Phase I of a DARPA funded linux kernel project

[Mike Waychison]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tim Hockin wrote:
> On Wed, Aug 25, 2004 at 04:25:24PM -0400, Rik van Riel wrote:
>
>>>You can think of this as chroot on steroids.
>>
>>Sounds like what you want is pretty much the namespace stuff
>>that has been in the kernel since the early 2.4 days.
>>
>>No need to replicate VFS functionality inside the filesystem.
>
>
> When I was at Sun, we talked a lot about this.  Mike, does Sun have any
> iterest in this?

Not that I know of.  I believe the functionality Hans is looking for has
already been handled by SELinux.  What is needed (if it doesn't already
exist) is a tool to gather these 'viewprints' automagically.

- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
http://www.sun.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBLQM4dQs4kOxk3/MRArXMAJ0WTzw8L/vLNO3lYwkCdGJGrzRBKgCcD7l7
w6eSrLFYVHoQ9CiAruQCV9E=
=PVV9
-----END PGP SIGNATURE-----

Re: Using fs views to isolate untrusted processes: I need an assistant architect in the USA for Phase I of a DARPA funded linux kernel project

[Kyle Moffett]

On Aug 25, 2004, at 16:56, Tim Hockin wrote:
> On Wed, Aug 25, 2004 at 04:25:24PM -0400, Rik van Riel wrote:
>>> You can think of this as chroot on steroids.
>>
>> Sounds like what you want is pretty much the namespace stuff
>> that has been in the kernel since the early 2.4 days.
>>
>> No need to replicate VFS functionality inside the filesystem.
>
> When I was at Sun, we talked a lot about this.  Mike, does Sun have any
> iterest in this?
>
> We found a lot of shortcomings in implementing various namespace-ish
> things.

Here's a simple way to do what you want in userspace:
1) Apply the kernel bind mount options fix (*)
2) Run the following shell script

cat <<'EOF' >fsviews.bash
#! /bin/bash
# First make the subdirectories
mkdir /fsviews_orig
mount -t tmpfs tmpfs /fsviews_rw
mkdir /fsviews_orig/dir1
mkdir /fsviews_orig/dir2
mkdir /fsviews_orig/old

# Now make it read-only with a copy in /fsviews
mkdir /fsviews
mount --bind /fsviews_orig /fsviews

# Put directories in /fsviews
mount --bind /somewhere/dir1 /fsviews/dir1
mount --bind -o ro /otherplace/dir2 /fsviews/dir2

# Start the process in a new namespace
clone_prog bash <<'BACK_TO_OLD_NAMESPACE'

mount -o ro,remount /fsviews_orig
pivot_root /fsviews /fsviews/old
umount -l /fsviews/old
/dir1/myscript &

BACK_TO_OLD_NAMESPACE

# Remove the extra dirs in this namespace
umount -l /fsviews
umount -l /fsviews_orig
rmdir /fsviews
rmdir /fsviews_orig

EOF

This assumes that clone_prog is a short C program that does a clone() 
syscall
with the CLONE_NEWNS flag and executes a new process.

Once this is done, "/dir2/script" is running in a _completely_ new 
namespace
with a read-only root directory and two directories from other parts of 
the vfs.

(*) IIRC currently bind-mount rw/ro options are those of the underlying 
mount,
the bind-mount options fix provides a separate set of options for each 
bound
copy.  There is only one minimal security implication without said 
patch, that
root can still 'mount -o rw,remount /' to get root writeable again, but 
since it's
on tmpfs, that doesn't matter much.  You could also just take away some
capabilities, but otherwise except for the shared process tables this 
acts very
much like a completely new, separate computer.  I've used this to 
thoroughly
secure minimally trusted daemons before. :-D

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a17 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------

Re: Using fs views to isolate untrusted processes: I need an assistant architect in the USA for Phase I of a DARPA funded linux kernel project

[Mike Waychison]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kyle Moffett wrote:
> On Aug 25, 2004, at 16:56, Tim Hockin wrote:
>
>> On Wed, Aug 25, 2004 at 04:25:24PM -0400, Rik van Riel wrote:
>>
>>>> You can think of this as chroot on steroids.
>>>
>>>
>>> Sounds like what you want is pretty much the namespace stuff
>>> that has been in the kernel since the early 2.4 days.
>>>
>>> No need to replicate VFS functionality inside the filesystem.
>>
>>
>> When I was at Sun, we talked a lot about this.  Mike, does Sun have any
>> iterest in this?
>>
>> We found a lot of shortcomings in implementing various namespace-ish
>> things.
>
>
> Here's a simple way to do what you want in userspace:
> 1) Apply the kernel bind mount options fix (*)
> 2) Run the following shell script
>
> cat <<'EOF' >fsviews.bash
> #! /bin/bash
> # First make the subdirectories
> mkdir /fsviews_orig
> mount -t tmpfs tmpfs /fsviews_rw
> mkdir /fsviews_orig/dir1
> mkdir /fsviews_orig/dir2
> mkdir /fsviews_orig/old
>
> # Now make it read-only with a copy in /fsviews
> mkdir /fsviews
> mount --bind /fsviews_orig /fsviews
>
> # Put directories in /fsviews
> mount --bind /somewhere/dir1 /fsviews/dir1
> mount --bind -o ro /otherplace/dir2 /fsviews/dir2
>
> # Start the process in a new namespace
> clone_prog bash <<'BACK_TO_OLD_NAMESPACE'
>
> mount -o ro,remount /fsviews_orig
> pivot_root /fsviews /fsviews/old
> umount -l /fsviews/old
> /dir1/myscript &
>
> BACK_TO_OLD_NAMESPACE
>
> # Remove the extra dirs in this namespace
> umount -l /fsviews
> umount -l /fsviews_orig
> rmdir /fsviews
> rmdir /fsviews_orig
>
> EOF
>
> This assumes that clone_prog is a short C program that does a clone()
> syscall
> with the CLONE_NEWNS flag and executes a new process.
>
> Once this is done, "/dir2/script" is running in a _completely_ new
> namespace
> with a read-only root directory and two directories from other parts of
> the vfs.
>
> (*) IIRC currently bind-mount rw/ro options are those of the underlying
> mount,
> the bind-mount options fix provides a separate set of options for each
> bound
> copy.  There is only one minimal security implication without said
> patch, that
> root can still 'mount -o rw,remount /' to get root writeable again, but
> since it's
> on tmpfs, that doesn't matter much.  You could also just take away some
> capabilities, but otherwise except for the shared process tables this
> acts very
> much like a completely new, separate computer.  I've used this to
> thoroughly
> secure minimally trusted daemons before. :-D
>
> Cheers,
> Kyle Moffett

This provides minimal protection if any: the user may remount any block
devices on any given tree in his 'namespace' (in the sense of "that is
what we call a mount-table in Linux").  *

If I understand what Hans is looking to get done, he's asking for
someone to architect a system where any given process can be restricted
to seeing/accessing a subset of the namespace (in the sense of "a tree
of directories/files").  Eg: process Foo is allowed access to write to
/etc/group, but _not_ allowed access to /etc/shadow, under any
circumstances && Foo will be run as root.  Hell, maybe Foo is never able
to even _see_ /etc/shadow (making it a true shadow file :).

Hans, correct me if I misunderstood.

[*] Somebody really should s/struct namespace/struct mounttable/g (or
even mounttree) on the kernel sources.  'Namespace' isn't very
descriptive and it leads to confusion :(

- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
http://www.sun.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBLSvRdQs4kOxk3/MRAnopAJ91xpTEqf1I/jaRdqbjbgfnNuPpugCfbkvz
VeJUBr2UuagZ5UGMGC1nebw=
=XuQT
-----END PGP SIGNATURE-----

Re: Using fs views to isolate untrusted processes: I need an assistant architect in the USA for Phase I of a DARPA funded linux kernel project

[Kyle Moffett]

On Aug 25, 2004, at 20:16, Mike Waychison wrote:
> Kyle Moffett wrote:
>> Here's a simple way to do what you want in userspace:
>> 1) Apply the kernel bind mount options fix (*)
>> 2) Run the following shell script
>>
>> cat <<'EOF' >fsviews.bash
>> #! /bin/bash
>> # First make the subdirectories
>> mkdir /fsviews_orig
>> mount -t tmpfs tmpfs /fsviews_rw
>> mkdir /fsviews_orig/dir1
>> mkdir /fsviews_orig/dir2
>> mkdir /fsviews_orig/old
>>
>> # Now make it read-only with a copy in /fsviews
>> mkdir /fsviews
>> mount --bind /fsviews_orig /fsviews
>>
>> # Put directories in /fsviews
>> mount --bind /somewhere/dir1 /fsviews/dir1
>> mount --bind -o ro /otherplace/dir2 /fsviews/dir2
>>
>> # Start the process in a new namespace
>> clone_prog bash <<'BACK_TO_OLD_NAMESPACE'
>>
>> mount -o ro,remount /fsviews_orig
>> pivot_root /fsviews /fsviews/old
>> umount -l /fsviews/old
>> /dir1/myscript &
>>
>> BACK_TO_OLD_NAMESPACE
>>
>> # Remove the extra dirs in this namespace
>> umount -l /fsviews
>> umount -l /fsviews_orig
>> rmdir /fsviews
>> rmdir /fsviews_orig
>>
>> EOF
>>
>> This assumes that clone_prog is a short C program that does a clone()
>> syscall
>> with the CLONE_NEWNS flag and executes a new process.
>>
>> Once this is done, "/dir2/script" is running in a _completely_ new
>> namespace
>> with a read-only root directory and two directories from other parts 
>> of
>> the vfs.
>>
>> (*) IIRC currently bind-mount rw/ro options are those of the 
>> underlying
>> mount,
>> the bind-mount options fix provides a separate set of options for each
>> bound
>> copy.  There is only one minimal security implication without said
>> patch, that
>> root can still 'mount -o rw,remount /' to get root writeable again, 
>> but
>> since it's
>> on tmpfs, that doesn't matter much.  You could also just take away 
>> some
>> capabilities, but otherwise except for the shared process tables this
>> acts very
>> much like a completely new, separate computer.  I've used this to
>> thoroughly
>> secure minimally trusted daemons before. :-D
>>
>> Cheers,
>> Kyle Moffett
>
> This provides minimal protection if any: the user may remount any block
> devices on any given tree in his 'namespace' (in the sense of "that is
> what we call a mount-table in Linux").  *

Ok, so just mount the whole darn thing with "-o nodev" :-D

> If I understand what Hans is looking to get done, he's asking for
> someone to architect a system where any given process can be restricted
> to seeing/accessing a subset of the namespace (in the sense of "a tree
> of directories/files").  Eg: process Foo is allowed access to write to
> /etc/group, but _not_ allowed access to /etc/shadow, under any
> circumstances && Foo will be run as root.  Hell, maybe Foo is never 
> able
> to even _see_ /etc/shadow (making it a true shadow file :).

I would find this much more useful if there was a really lightweight 
bind
mount called a "filebind" or somesuch that could only bindmount files 
and
not directories but had a much lower cost.  Actually, on that issue, 
have
there been any extensive benchmarks on the scalability of bind mounts?
I'm curious how much of a performance hit they place on directory 
lookups.

With a lightweight "filebind" you could generate such a namespace with
the above script and a list of files/directories to give access to. One 
other
useful feature would be a bind mount user-override and umask:

# ls -alh /foo
drwxr-xr-x    2 root root 4.0K Aug 25 20:33 .
drwxr-xr-x   13 root root 4.0K Aug 25 20:33 ..
-rwxr-xr-x    1 root root 0 Aug 25 20:33 baz
# mount --bind -o forceuid=1000,filemask=0137,dirmask=0026 /foo /bar
# ls -alh /bar
drwxr-x---    2 1000 1000 4.0K Aug 25 20:33 .
drwxr-xr-x   13 root root 4.0K Aug 25 20:33 ..
-rw-r-----    1 1000 1000 0 Aug 25 20:33 baz
#

This would be a really useful feature.  It would be nice if there was 
some
common VFS mountpoint layer that transparently provided these kinds
of options (And ro,rw,nodev,etc) for all mounted objects (be they bind
mounts or filesystems.  With this, vfat, iso9660, etc could share an
implementation. (Although I could be just blatantly missing where all of
this is actually implemented properly, so if I'm wrong somewhere,
please do correct me :-D)

> Hans, correct me if I misunderstood.
>
> [*] Somebody really should s/struct namespace/struct mounttable/g (or
> even mounttree) on the kernel sources.  'Namespace' isn't very
> descriptive and it leads to confusion :(

Or maybe somebody should s/namespace/file access mask/ on this
thread :-D.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a17 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------

Re: Using fs views to isolate untrusted processes: I need an assistant architect in the USA for Phase I of a DARPA funded linux kernel project

[Chris Wright]

* Mike Waychison (Michael.Waychison@Sun.COM) wrote:
> This provides minimal protection if any: the user may remount any block
> devices on any given tree in his 'namespace' (in the sense of "that is
> what we call a mount-table in Linux").  *

Namespaces aren't currently expressive enough, and have caveats like
these, and can't express detailed access controls.

> If I understand what Hans is looking to get done, he's asking for
> someone to architect a system where any given process can be restricted
> to seeing/accessing a subset of the namespace (in the sense of "a tree
> of directories/files").  Eg: process Foo is allowed access to write to
> /etc/group, but _not_ allowed access to /etc/shadow, under any
> circumstances && Foo will be run as root.  Hell, maybe Foo is never able
> to even _see_ /etc/shadow (making it a true shadow file :).

This has already been done.  LSM provides the infrastructure, things
like LIDS and SubDomain do this fairly directly.  SELinux does this as
well using types as an intermediary.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: Using fs views to isolate untrusted processes: I need an assistant architect in the USA for Phase I of a DARPA funded linux kernel project

[Chris Wright]

* Kyle Moffett (mrmacman_g4@mac.com) wrote:
> I would find this much more useful if there was a really lightweight 
> bind
> mount called a "filebind" or somesuch that could only bindmount files 

This already works.

# cd /tmp
# echo foo > a
# touch b
# mount --bind a b
# cat b
foo

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: Using fs views to isolate untrusted processes: I need an assistant architect in the USA for Phase I of a DARPA funded linux kernel project

[Kyle Moffett]

On Aug 25, 2004, at 21:06, Chris Wright wrote:
> * Kyle Moffett (mrmacman_g4@mac.com) wrote:
>> I would find this much more useful if there was a really lightweight
>> bind
>> mount called a "filebind" or somesuch that could only bindmount files
> This already works.
>
> # cd /tmp
> # echo foo > a
> # touch b
> # mount --bind a b
> # cat b
> foo

I'm well aware of the technique, but I was wondering if there was any
extra VFS baggage associated with a normal bind mount that might
be eliminated by restricting a different version of a bind mount to only
files.  That's why I asked later if anybody had benchmarked the bind
mount system to see how well it would scale to 1000 bound files and
directories.  If it's not a performance issue then I really don't care 
less,
but I have a somewhat old box that must make do as a fileserver, so
I'm very interested in maximizing the performance. I don't care much
about extra RAM consumption, only about CPU and bus usage.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a17 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------

Re: Using fs views to isolate untrusted processes: I need an assistant architect in the USA for Phase I of a DARPA funded linux kernel project

[viro]

On Thu, Aug 26, 2004 at 12:16:43AM -0400, Kyle Moffett wrote:
> I'm well aware of the technique, but I was wondering if there was any
> extra VFS baggage associated with a normal bind mount that might
> be eliminated by restricting a different version of a bind mount to only
> files.  That's why I asked later if anybody had benchmarked the bind
> mount system to see how well it would scale to 1000 bound files and
> directories.  If it's not a performance issue then I really don't care 
> less,
> but I have a somewhat old box that must make do as a fileserver, so
> I'm very interested in maximizing the performance. I don't care much
> about extra RAM consumption, only about CPU and bus usage.

Files and directories are not different in that respect - the only overhead
is price of hash lookup when crossing the binding in either case.  1000
bindings shouldn't be a problem - it's 3--5 per hash chain.  Wrt memory,
it's one struct vfsmount allocated per binding - IOW, about 80Kb total
for 1000 of those.

Re: Using fs views to isolate untrusted processes: I need an assistant architect in the USA for Phase I of a DARPA funded linux kernel project

[Kyle Moffett]

On Aug 26, 2004, at 00:29, viro@parcelfarce.linux.theplanet.co.uk wrote:
> Files and directories are not different in that respect - the only 
> overhead
> is price of hash lookup when crossing the binding in either case.  1000
> bindings shouldn't be a problem - it's 3--5 per hash chain.  Wrt 
> memory,
> it's one struct vfsmount allocated per binding - IOW, about 80Kb total
> for 1000 of those.

Where would I increase the hash size if I wanted to increase the number
of bindings by an order of magnitude or so?  I'm very interested in
pursuing this possibility, because when combined with the procedure I
described earlier, plus a little bit of extra work with capabilities 
and such
it's very easy to build incredibly flexible and basically indestructible
chroot environments with not much code.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a17 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------

Re: Using fs views to isolate untrusted processes: I need an assistant architect in the USA for Phase I of a DARPA funded linux kernel project

[viro]

On Thu, Aug 26, 2004 at 12:52:37AM -0400, Kyle Moffett wrote:
> Where would I increase the hash size if I wanted to increase the number
> of bindings by an order of magnitude or so?  I'm very interested in
> pursuing this possibility, because when combined with the procedure I
> described earlier, plus a little bit of extra work with capabilities 
> and such
> it's very easy to build incredibly flexible and basically indestructible
> chroot environments with not much code.

*shrug*

fs/namespace.c::mnt_init().  Right now it allocates 1 page for hash table
(order = 0), you can easily raise that.  You might want to try and change
the order of checks in lookup_mnt() loop - depending on your setup it
might speed the things up, but I doubt that it would be noticable win.

Re: Using fs views to isolate untrusted processes: I need an assistant architect in the USA for Phase I of a DARPA funded linux kernel project

[Hans Reiser]

Mike Waychison wrote:

> Tim Hockin wrote:
>
> >On Wed, Aug 25, 2004 at 04:25:24PM -0400, Rik van Riel wrote:
>
> >>>You can think of this as chroot on steroids.
> >>
> >>Sounds like what you want is pretty much the namespace stuff
> >>that has been in the kernel since the early 2.4 days.
> >>
> >>No need to replicate VFS functionality inside the filesystem.
>
>
> >When I was at Sun, we talked a lot about this.  Mike, does Sun have any
> >iterest in this?
>
>
> Not that I know of.  I believe the functionality Hans is looking for has
> already been handled by SELinux.

Everybody who takes a 3 minute read of SELinux keeps saying it has, but 
it hasn't quite, not when you look at the details.  SELinux is not 
written by filesystem folks, and there are scalability details that matter.

> What is needed (if it doesn't already
> exist) is a tool to gather these 'viewprints' automagically.

It doesn't exist, and viewprints are also not stored with executables 
either, so it is not process oriented.

People think the problem is allowing the OS to enact fine grained 
security.  It is not.  The problem is allowing the user to enact fine 
grained security, and without a lot of work to automate it, users will 
continue to be unable to bear that time cost.

>
> --
> Mike Waychison
> Sun Microsystems, Inc.
> 1 (650) 352-5299 voice
> 1 (416) 202-8336 voice
> http://www.sun.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> NOTICE:  The opinions expressed in this email are held by me,
> and may not represent the views of Sun Microsystems, Inc.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: Using fs views to isolate untrusted processes: I need an assistant architect in the USA for Phase I of a DARPA funded linux kernel project

[Hans Reiser]

Mike Waychison wrote:

>
>
> If I understand what Hans is looking to get done, he's asking for
> someone to architect a system where any given process can be restricted
> to seeing/accessing a subset of the namespace (in the sense of "a tree
> of directories/files").  Eg: process Foo is allowed access to write to
> /etc/group, but _not_ allowed access to /etc/shadow, under any
> circumstances && Foo will be run as root.  Hell, maybe Foo is never able
> to even _see_ /etc/shadow (making it a true shadow file :).

You are correct, you cannot even see /etc/shadow.

The term mask may be more communicative than view.  We are starting to 
use the term mask.

>
> Hans, correct me if I misunderstood.
>
> [*] Somebody really should s/struct namespace/struct mounttable/g (or
> even mounttree) on the kernel sources.  'Namespace' isn't very
> descriptive and it leads to confusion :(
>
> --
> Mike Waychison
> Sun Microsystems, Inc.
> 1 (650) 352-5299 voice
> 1 (416) 202-8336 voice
> http://www.sun.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> NOTICE:  The opinions expressed in this email are held by me,
> and may not represent the views of Sun Microsystems, Inc.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: Using fs views to isolate untrusted processes: I need an assistant architect in the USA for Phase I of a DARPA funded linux kernel project

[Hans Reiser]

Rik van Riel wrote:

>On Sun, 1 Aug 2004, Hans Reiser wrote:
>
>  
>
>>You can think of this as chroot on steroids.
>>    
>>
>
>Sounds like what you want is pretty much the namespace stuff
>that has been in the kernel since the early 2.4 days.
>
>No need to replicate VFS functionality inside the filesystem.
>
>  
>
It differs in that it has masks (view specifications), they scale well, 
their collection and specification is well automated, and they are 
attached to the process executable rather than in some centralized place 
(that is, they are process oriented not object oriented (traditional) 
and not centralized.  Users without root can use them and be trusted 
with the power to do so.

Hans

Re: Using fs views to isolate untrusted processes: I need an assistant architect in the USA for Phase I of a DARPA funded linux kernel project

[Stephen Smalley]

On Thu, 2004-08-26 at 02:31, Hans Reiser wrote:
> Everybody who takes a 3 minute read of SELinux keeps saying it has, but 
> it hasn't quite, not when you look at the details.  SELinux is not 
> written by filesystem folks, and there are scalability details that matter.

I don't quite see the point about filesystem folks.
With regard to scalability, there is ongoing work in that area, and
patches on lkml that are being discussed even now, so that is hardly a
show stopper.

> > What is needed (if it doesn't already
> > exist) is a tool to gather these 'viewprints' automagically.
> 
> It doesn't exist, and viewprints are also not stored with executables 
> either, so it is not process oriented.
> 
> People think the problem is allowing the OS to enact fine grained 
> security.  It is not.  The problem is allowing the user to enact fine 
> grained security, and without a lot of work to automate it, users will 
> continue to be unable to bear that time cost.

Users don't want to think about fine grained security at all, and
automated schemes will inevitably generate policies that are insecure ;)

SELinux already has a significant corpus of policy that has been
developed over time, most of it contributed by external contributors,
with > 190 different program domains in the current example policy.  It
has the obvious simple tool for generating policy from audit messages
produced during a run of a program, but that tool has certainly not been
a good source for secure policy.  It has tools for analyzing policies,
including information flow and goal checking, although much work still
remains to be done here.  Much better investment to work on improving
SELinux in these areas than re-inventing the wheel...

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency