Re: [dev] sup - the minimalistic sudo
I know that there's a really-cool mail client called 'sup'.. so if you have any other proposal for the name? 's'? 'sp'? 'sudor'? smudo? a jungled-up acronym for minimal super do? Kind of a german insider, but it has a nice ring to it ;) I like sup alot, btw.
Re: [dev] sup - the minimalistic sudo
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?
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
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 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
Re: [dev] sup - the minimalistic sudo
On 12/14/2009 07:25 PM, Uriel wrote: 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 can you argument in few lines about this security model and why is better than my proposal? and ofcourse..why its elegant, simpler and effective, those are easy to say words but certainly i dont know plan9 that much to discuss that. A more than 2urls reply would be more constructive for the thread. Sudo? who the hell needs that, just get rid of root already. for me the 'root' user is a simplification for a user with all priviledges (which is not true at all, because kernel have more priviledges than root) In hurd you have a guest user with really low priviledges which requires no login. it is fun... but i have never find a real use case a part from finding a file on the filesystem before login to change the bootloader configuration. Thanks for the plan9 caps info, didnt knew that. --pancake
