Re: [dev] sup - the minimalistic sudo

Plan 9 has /dev/cap* which provides a simple, elegant and effective
capability system where it is really useful, without changing any of
the unix permissions model (other than being saner and simplified).

http://man.cat-v.org/plan_9/3/cap
http://doc.cat-v.org/plan_9/4th_edition/papers/auth

Sudo? who the hell needs that, just get rid of root already.

uriel

On Mon, Dec 14, 2009 at 7:03 PM, pancake <pancake_AT_youterm.com> wrote:
> 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:25:01 UTC