>
> I think this can be done with one program that can grant arbitrary
> capabilities, say /bin/caps, as in your scheme. /bin/caps would take a
> command and argument like, say, strace or time, but would just acquire and
> relinquish the "right" capabilities and then do the exec().
>
you can't *grant* capabilities to a running process, you can only revoke
your own. That's the whole idea behind it.
user space does not have access to the relevant structs to do it
otherwise. The only way that anything can get more caps than the
executing
process has right now, is by letting it do by the kernel during exec.
which does not means that a deamon (started by a process with all
necessary
caps) is something that won't work! If it can be poked to exec a
specified binary, removing only those caps it doesn't want to give
the new process.
something like this :
- deamon is started by init (which has all caps) and waits on port
for some command
- check if requested binary is known and which caps it should have
- fork -> old process returns to waiting
- revoke caps until it corresponds to what new binary is allowed
- exec requested binary.
of course the most difficult part would be to make a secure API
which calls on to this deamon.
(doesn't this give you the shivers ;o) )
> > In a very simple example you would have a file called /etc/caps.conf that
> > would have the user/file information:
>
> > #user:file:caps
> > root:*:*
> > backup:/bin/tar:READ_ALL,BACKUP,RESTORE
> > joe:*:SECURITY
>
> > root would be all powerful. backup could poke around and such. joe could
> > create users, set passwords and other things of that nature.
>
> There is no need for a daemon, but I would make the .conf files more
> flexible; ie., what you have could become
> /etc/caps.user.conf:
> #user : caps
> root : *
> backup : READ_ALL, BACKUP, RESTORE
> joe : SECURITY
>
> and
> /etc/caps.progs.conf:
> #prog : caps : negative caps
> /bin/ping.cap : SOCK_RAW :
> /usr/X11R6/bin/Xwrapper.cap : VIDEO :
> /.../untrusted/proprietary/app : : ROOT_RIGHTS
>
> so that ping and X work as expected, and also no matter who runs the
> untrusted program, it will not be able to do more damage than if run by an
> "ordinary" user, no matter how poorly coded it is.
fine for a user table, however how can you figure out if somebody swaped
your executable while you weren't looking ? a capability must be tied
stronger than that to a specifique executable. specially if you allow
capabilities to user execs.
unless this table is read at boot time (by deamon above), and a lock is
set on each of these executables pinning a binary in place. I think this
is the way of VMS. Still, I think you would need kernel help to do this
>
> It may be that there's some way to use a daemon so that all the
> capabilities config files don't need to be read and parsed every time
> /bin/caps is invoked.
yea.
but you would still need to modify all existing programs.
I still think it's best to go for FS support
E.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/