Re: [dev] sup - the minimalistic sudo

On 12/14/2009 02:48 PM, Daniel Cordero wrote:
> On Mon, Dec 14, 2009 13:51:13 +0100, pancake wrote:
>
>> Hopefully this will be part of the stali userland.
>>
>>
> Can't stali use capabilities instead?
>
>
In monolithic kernels i have always seen the capabilities like
the ACLs.. they resolve the same problems as unix do in a simple way,
but doing it in a really unmaintainable and complicated way which
opens the doors to many problems.

The problem of capabilities is that there are thousands of "caps"
to restrict or provide to an application. but this will make the
system unmaintainable.

For example, if you add full access to drives, because the user
needs to burn dvds, and you think that this is ok, because it is
secure... well.. the problem is that such capability is problematic
enought to cause hardware deadlocks, kernel crashes, exploit
kernel vulnerabilities to bring ring0 shell and so.

Im not talking about theories here.. i have found some of those
vulnerabilities on linux and solaris kernels, but they are broken
by design.

The problem in capabilities is that they give power to a single
application to do something, this makes the developers think that
it is secure enought to give such capabilities to the whole
application instead of splitting such functionalities on a separate
process or thread, making the 'critic' routine as short as possible
making the code auditing and the interference with the external
environment as minimal as possible.

I understand that in many of situations it is ok to only give permissions
to do some kind of stuffs to an application..but capabilities concept
is broken from my point of view.

In a microkernel system you can make each service share its capabilities
via a virtual filesystem, so you can use normal filesystem protections
or change visibility over the filesystem to each application to reduce
the capabilities of an application.

Following this way you dont need a root user, because you can have
different users, programs with different views of the system and having
a simple design and interface to control such perspectives.

Another point for not using capabilities is that they are really system
specific, and I really dislike linux, so if we want to run stali base
system on BSD or any other kernel we will not be able to do it.

IMHO we should end up designing a kernel...or just enhace plan9.

The idea of 'sup' is to be compiled, not only at system level, also
for specific users, or environments, so you can have different sups
to run commands in chroots, users, etc.. giving the right permisions
to the sup binary (chmod 4100) and so on.

Another protection I was thinking on was to add support to sup to compare
a checksum before executing the target binary, this way if the target
program changes or gets trojanized you can notice this.

The point of this is that all programs that must be run from sup should
be only writable by root, and the root user should be used as less as
possible.

  .. this is the idea of the ENFORCE define in config.h

--pancake
Received on Mon Dec 14 2009 - 18:03:01 UTC