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

[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