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

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.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Christian" == Christian Mayrhuber <[email protected]> writes:

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

"Christian" == Christian Mayrhuber <[email protected]> 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.

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

"Christian" == Christian Mayrhuber <[email protected]> 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.

Quoted 7 lines · Hubert Chan

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

"Christian" == Christian Mayrhuber <[email protected]> writes:

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

Quoted 11 lines

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.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"David" == David Greaves <[email protected]> writes:

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"David" == David Greaves <[email protected]> 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.)

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.

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

Quoted 6 lines · 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).

Quoted 9 lines

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

You can think of this as chroot on steroids.

Quoted 1 line

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.

Quoted 2 lines · Rik van Riel

Quoted 1 line

You can think of this as chroot on steroids.

Quoted 4 lines

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?

Quoted 8 lines · Tim Hockin

Quoted 6 lines · Rik van Riel

Quoted 1 line

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.

Quoted 2 lines

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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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.

Quoted 2 lines

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.

Quoted 5 lines · Rik van Riel

Quoted 1 line

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.

Quoted 1 line

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.

Quoted 8 lines · Tim Hockin

Quoted 6 lines · Rik van Riel

Quoted 1 line

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.

Quoted 8 lines

Quoted 1 line

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

Quoted 63 lines · Kyle Moffett

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

Quoted 2 lines

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 :(

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

Quoted 3 lines · * Kyle Moffett ([email protected]) 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.

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.

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 :).

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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

On Sun, 1 Aug 2004, Hans Reiser wrote:

Quoted 3 lines

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.