re: User-manageable sub-ids proposals

re: User-manageable sub-ids proposals

[Jacques Gelinas]

On Thu, 13 Dec 2001 11:36:16 -0500, Romano Giannetti wrote
> Good morning to everyone.
>
> I was thinking about the idea of sub-ids to enable users to run "untrusted"
> binary or "dangerous" one without risk for their files/privacy.

I have another solution, which is almost completed. I am combining
two project. One is the vserver project (see the url in my signature) and the
other is the AclFS component of the virtualfs project
(http://www.solucorp.qc.ca/virtualfs).

Using the chcontext utility from the vserver project, you can isolate a process
from the rest of the system, including the other user processes

For example, as a normal user, you can do

	xterm &
	/usr/sbin/chcontext /bin/sh
	ps ax
	killall xterm

and you only see your new shell, the ps command and init. The killall fails
finding no xterm to kill.

Another part of the vserver project is the capability ceiling, which is a way to
turn off some capabilities for a process and its children, even setuid child.

I was thinking about introducing a new capability CAP_OPEN. This capability
would prevent any open system call from succeeding. Wow. Now that's secure :-)

The acslfs daemon works using a unix domain socket. Using a preload object
the client does various system call request to aclfsd, including open, socket
and so on. If aclfsd grant the access, it opens the file and pass back the
file handle using the socket. So the client does not need to open the file
itself.

So the CAP_OPEN is there to force the client to use aclfsd. Even if using aclfsd
is transparent to normal clients, some client might do a direct call to the OS.
All those calls would fail.

Not also that aclfsd does not need any privilege. A normal user may start
it with its own configurations (access privileges).

Ultimatly, one goal of this would be to run your favorite browser in a security
box and allow fine grain access to your own file. Then one could do the so
cool thing windows user do all the time: They visit a site, select a plugin
and run it. Unlike windows, you would not get all the virus though :-)

Anyway, the vserver and virtual projects are used for different purpose today
but could be combined to achieve this kind of result.

---------------------------------------------------------
Jacques Gelinas <jack@solucorp.qc.ca>
vserver: run general purpose virtual servers on one box, full speed!
http://www.solucorp.qc.ca/miscprj/s_context.hc

Re: User-manageable sub-ids proposals

[Andreas Ferber]

On Thu, Dec 13, 2001 at 11:36:16AM +0100, Romano Giannetti wrote:
> 
> I was thinking about the idea of sub-ids to enable users to run "untrusted"
> binary or "dangerous" one without risk for their files/privacy. 

Most parts of your proposal can be implemented in userspace, without
any kernel changes.

In fact, most parts /are/ already implemented, and only waiting to be
configured properly. It's called "sudo".

The only deficiency of the userspace only approach I see at the moment
is that you can't impersonate the slave user from the main user id
regarding to filesystem access. This can be worked around with proper
permissions if you take the "one group/one user" approach, all
slave users will have the main users group.

Andreas
-- 
       Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
     ---------------------------------------------------------
         +49 521 1365800 - af@devcon.net - www.devcon.net

Re: User-manageable sub-ids proposals

[Pavel Machek]

Hi!

> And we end up with a different solution:
> olduid=getuid();
> /* Allocate a uid with no privilegies */

Dangerous. Imagine:

	while (1) {

Re: User-manageable sub-ids proposals

[David Wagner]

Romano Giannetti  wrote:
>I was thinking about the idea of sub-ids to enable users to run "untrusted"
>binary or "dangerous" one without risk for their files/privacy. 

Can I point you to some work I've done on this topic?
We built a tool called Janus (alas, it required kernel patches).
http://www.cs.berkeley.edu/~daw/janus/

Your basic goal seems like a good one: it'd be really nice if you could
run untrusted code in a sandbox that nothing can escape.  Based on
our experience, though, I've come to believe you probably want a more
sophisticated solution than the one you outlined.

First, the 'nobody' userid (and equivalents) leave a lot to be desired.
A troubling number of system resources can be accessed by 'nobody': there
are usually an enormous quantity of world-readable files; more troubling,
there are tons of world-executable setuid programs, and it's hard with a
purely userid-based mechanism to be sure that they won't provide an escape
hatch; not to mention other resources, such as interprocess communication,
network sockets, and so on.

The conclusion we came to is that you really need something more powerful
than the existing access control measures.  Unix systems are really not
very good at preventing attacks by local users.

A second claim is that you really want to start from the Principle
of Least Privilege: give the untrusted process the absolute minimum
privilege necessary for it to accomplish its task, and nothing more.
Userid-based mechanisms do a lousy job at achieving this.

This, by the way, is analogous to the "default deny" policy that you may
be familiar with from the firewalls world: if you start by giving the
untrusted process zero privileges and then explicitly declare only the
ones you want allowed, you greatly reduce the risk that the untrusted
process can escape and cause harm in some way you didn't expect.

A third observation is that you need to control access to a lot more
than just the filesystem.  You want to control the network (prevent the
spread of viruses; and if anyone uses IP-based authentication, or if
your machine is inside a firewall, prevent the untrusted process from
abusing the good name of the local host).  You want to control resources
like IPC, signals, resource usage, and so on.  And I claim you want more
fine-grained control than POSIX capabilities provide.

A fourth observation is that in practice it's useful to provide more
than just isolation: you often also want to allow some limited degree
of sharing between trusted and untrusted processes.  chroot() is not
so good in this respect, even apart from the fact that it protects only
the filesystem and not any of the other resources on the system.

The Janus approach is to interpose on system calls to impose a more
restrictive security policy.  We use ptrace() and the like to do this
from userspace.  It's a little clunky, especially since support for
process tracing on Linux has shortcomings, but it works.  We've run
a web browser, a web server, etc., inside the restricted environment
Janus provides.  Janus is just one approach, of course, and there are
a number of other projects that have followed related directions (DTE,
consh, mapbox, SubDomain, SELinux, etc.).

Looking to the future, may I direct your attention to the Linux Security
Module project?  They're doing some great work that I think will lay
a fantastic foundation for trying out many different approaches to
this problem.

Re: User-manageable sub-ids proposals

[Ragnar Kjørstad]

On Thu, Dec 13, 2001 at 05:06:29PM +0100, Romano Giannetti wrote:
> > 2 do we want the "slave" to be able to write the users files
> 
> Generally no, but you can create a dir where the slave uid can create file
> (think to a java applet that need temporary files, etc...) 

I think generally temporary files should go to /tmp and not the home
directory, but yes, there may be reasons to write to specific files in
the home directory as well.

> > This should also be possible to implement with minimal impact. All you
> > need is a new systemcall to allocate a uid for the slave. This means you
> > need to reserve some uids for this purpose, but with 32bit uids......
> 
> Yes, but then the slave process is very much _very_ limited. It could need
> to read/map dynamic libraries, for example; with my approach the slave uid
> processes are processes that have a full-level citizenship and that can do
> anything a process can do, but under a different name than the user. Root
> uses "nobody" to this extent sometime; my proposal is to extend this to
> every (unprivileged) user in a safe way. Then, you can create a chrooted
> environment for the new process and tailor the level of access it has
> depending on the needs.

Why would the slave not be able to read/map dynamic libraries in my
sceeme? Such files should be readable by everyone, so I don't see the
problem?

With ACL support I don't see this beeing limited at all. The process can
be given any rights you desire before changing it's effective userid.


-- 
Ragnar Kjørstad
Big Storage

Re: User-manageable sub-ids proposals

[Romano Giannetti]

On Thu, Dec 13, 2001 at 02:37:52PM +0100, Ragnar Kjørstad wrote:
> On Thu, Dec 13, 2001 at 11:36:16AM +0100, Romano Giannetti wrote:
> > I am romano, uid 300.
> > There is(/are) another(s) user, for example r-slave, uid 3001, no login
> > shell, with home dir in ~romano/r-slave.
> 
> It would be so much nicer to be able to do this on-the-fly, rather than
> having to create the user and it's home directory first.

Yes, this could be nice.

> However, I think one must first start with figguring out what
> functionality we want:
> 1 do we want the "slave" to be able to read the users files

Yes, but _by default_ the slave process could read only the files that you
have world readable (or group readable, if the slave is in the same group
than you, which probably is not a good idea). So you could decide wich file
it can access and which not.

> 2 do we want the "slave" to be able to write the users files

Generally no, but you can create a dir where the slave uid can create file
(think to a java applet that need temporary files, etc...) 

> 3 do we want the "slave" to keep is own configuration files

Define the slave uid to have the same home dir than the main user...

> 
> This should also be possible to implement with minimal impact. All you
> need is a new systemcall to allocate a uid for the slave. This means you
> need to reserve some uids for this purpose, but with 32bit uids......
> 

Yes, but then the slave process is very much _very_ limited. It could need
to read/map dynamic libraries, for example; with my approach the slave uid
processes are processes that have a full-level citizenship and that can do
anything a process can do, but under a different name than the user. Root
uses "nobody" to this extent sometime; my proposal is to extend this to
every (unprivileged) user in a safe way. Then, you can create a chrooted
environment for the new process and tailor the level of access it has
depending on the needs.

                          Romano

-- 
Romano Giannetti             -  Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416  fax +34 915 411 132

Re: User-manageable sub-ids proposals

[Ragnar Kjørstad]

On Thu, Dec 13, 2001 at 11:36:16AM +0100, Romano Giannetti wrote:
> I am romano, uid 300.
> There is(/are) another(s) user, for example r-slave, uid 3001, no login
> shell, with home dir in ~romano/r-slave.

It would be so much nicer to be able to do this on-the-fly, rather than
having to create the user and it's home directory first.

However, I think one must first start with figguring out what
functionality we want:
1 do we want the "slave" to be able to read the users files
2 do we want the "slave" to be able to write the users files
3 do we want the "slave" to keep is own configuration files

And I think the answers are:
1. No. It would make it possible for broken/evil programs
   to steal your data.
2. Definitively not
3. No - it would cause different "slave" processes interact.
   It should rather use the users regular configuration files.

And we end up with a different solution:
olduid=getuid();
/* Allocate a uid with no privilegies */
slaveuid=setruid_slave(); 
set_acl("private-file", ACL_READ, slaveuid);
set_acl("private-log", ACL_APPEND, slaveuid);
seteuid(slaveuid);
exec("dangerous-program");


This should also be possible to implement with minimal impact. All you
need is a new systemcall to allocate a uid for the slave. This means you
need to reserve some uids for this purpose, but with 32bit uids......

A possible addon would be a systemcall to free the uid when it was not
in use anymore, so it can be reused safely. 

An alternative would be to not give the new uid access to the files, but
just open them before doing exec. This way it is safe to run multiple
slaves with the same uid at once, and it doesn't rely on ACLs! The
downside is that it needs cooperation from the dangerous-program, while
the above could work as long as the wrapper (e.g. a browser) took the
appropriate steps.


-- 
Ragnar Kjørstad
Big Storage

User-manageable sub-ids proposals

[Romano Giannetti]

Good morning to everyone.

I was thinking about the idea of sub-ids to enable users to run "untrusted"
binary or "dangerous" one without risk for their files/privacy. 

I had an idea to a low-profile, almost no invasive way to implement it that
should be almost transparent to user-space application (almost all). Let me
explain with an example. 

Let's add to task_struct another array like groups[NGROUPS], calling it
slave_uids[NSLAVES]. Add a (privileged) syscall, addslave(uid_t, uid_t), 
that can fill that arrays.

Now, the user space configuration is the following: 

I am romano, uid 300.
There is(/are) another(s) user, for example r-slave, uid 3001, no login
shell, with home dir in ~romano/r-slave.

When I login as romano, the login binary call a addslave(300, 3001), looking
at a /etc/slaves that has a line that says romano:r-slave

Now change the kernel so that: 

1) user romano can do a setuid() call to become anyone of its slaves, with
   no way back possible. 

2) user romano can chown() files owned by him and by any of its slaves to
   any of the romano or slaves uids. 

And that's all. All the other strange file management that user romano would
want to do on the slave-id environment, he can do by doing a kind-of-su(*)
to one of its slaves (with setuid) and then play in the restricted
enviroment. If you add ACL to this(**), you could easily fine-control what the
untrusted binary can see of your environment; add the per-vfsmount ro-flag
and it gives to you a lot of flexibility. 

This should be a change simple enough for the kernel, and for the userspace
too: just change login to add addslave call, and the tools that need to
spawn untrusted binaries can do a setuid() to a slave before the exec(). 

Is there something that I am missing here? 

                 Romano 


(*) probably to be called giu... (sorry, Italian-speaking only joke: /su/
means 'up' in Italian, and /giu/ means 'down'). 

(**) and without ACL, if you makes a parallel thing for gid, you can
probably fine-tune access in the old-style ways, provided that the system
set-up is the "every user in its own group" style.


-- 
Romano Giannetti             -  Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416  fax +34 915 411 132