Messages in this thread | | | Date | Sun, 29 Mar 1998 13:35:14 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: Securelevel bitmap patch |
| |
On Sun, 29 Mar 1998, Alan Cox wrote:
> > For example, I would personally never be interested in using the BSD kind > > of securelevels: by design the BSD securelevels would prevent me from > > doing exactly the kinds of things I need to do (ie install a new kernel > > and reboot, which is a very obvious security risk). > > So you don't use them. According to the figures there are about 5,999,999 > other Linux users however some of whom probably wish they had better > security.
Are you being dense on purpose?
I gave you the alternative I'd prefer, which handles _everybody's_ needs. And it handles them a lot better than the BSD securelevels, because there are going to be other people like me to whome the BSD securelevels simply will not cut it. Not now, not ever.
> Tell me Linus, you don't have a 3c509 ethernet card, why don't you just > delete all the drivers ? ie - I don't see your argument.
If I had a global ethernet driver that could handle all different device requirements with no more overhead than a single driver, I _would_ delete the 3c509 driver.
Not doing so would be extremely stupid - why should I maintain both drivers when one of them does the job and works much better and is obviously superior (it would work not only on 3c509 machines, but on the etherexpress etc too, with no extra overhead or complexity).
I just showed you such a "driver" - a securelevel setup that is no more expensive than the BSD securelevels, yet is able to handle a lot more interesting cases. In my opionion, I _would_ be extremely stupid to accept the BSD securelevel patches, when I _know_ there is a better way.
> And tell me how if you inherit securelevels you prove that every process > is subject to the desired restraints. Do you walk the process tree removing > bits from each process. We could do it that way I guess.
Yes. We already have a complete list of all processes, so globally removing some capability is a trivial matter of about 5 lines of code or so:
read_lock(&task_list_lock); for_each_task(p) { p->capability &= mask; } read_unlock(&task_list_lock);
but even more importantly, because we have a per-process mask we can also do things like remove privileges from only certain processes. And obviously the capability to remove capabilities would be another capability.
Even more importanly, you can _add_ capabilities. You might well want to have a "secure capability server", which would be the only process in the system that has the right to _grant_ privileges to others (ie or in new bits). Kerberos-like "tickets" (well, not really kerberos-like, but you get the idea).
> It would cost > 4 bytes per process, take a lot longer to set the values and do the same thing.
Oohh.. Yes, it costs you 32 bits per process. If you tell me you are worried about that, I tell you that you're either lying or have extremely poor judgement. In fact, you probably want another bitmask which specifies which bits can be inherited by children (if you have a capability to add capabilities, then you probably also want to specify that it is only added to this process, not to the children of this process - that way you can easily revert the capability forcibly if you want to at a later date).
So yes, it could easily add 8 bytes per process.
But by having a per-process bitmask you get - much better security granularity - faster security checking ("suid()" can now be _part_ of the capabilities, so you don't have to test it explicitly) - soemthing that people like me find useful, which is not true of the BSD crap.
Again, I don't see your points. Capability bitmasks are _obviously_ a true superset of the BSD security levels, so any security argument for a BSD securitylevel applies equally for capabilities. And I have already shown you two real-world cases where capabilities can be used for things that the BSD securitylevels simply have no way of handling at all.
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |