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 <panc...@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 > >