Re: [dev] sup - the minimalistic sudo

From: Uriel <>
Date: Mon, 14 Dec 2009 19:25:01 +0100

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

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


On Mon, Dec 14, 2009 at 7:03 PM, pancake <> 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

This archive was generated by hypermail 2.2.0 : Mon Dec 14 2009 - 18:36:02 UTC