lkml.org 
[lkml]   [1998]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.110 / U:0.648 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site