lkml.org 
[lkml]   [1998]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Securelevel bitmap patch
Linus Torvalds wrote:
>
> On Mon, 30 Mar 1998, Richard Gooch wrote:
> > >
> > > read_lock(&task_list_lock);
> > > for_each_task(p) {
> > > p->capability &= mask;
> > > }
> > > read_unlock(&task_list_lock);
> >
> > Or have a global mask, as has already been pointed out. Just trade off
> > the time for a global change with the time for each check.
>
> Yes, that does the above particular case, but I'd really like to see the
> "give capabilities to processes" too, so I think it makes sense to have a
> special process with extra privileges irrespective of the "global" mask.
>
> So yes, a global mask would be a simple solution, and might be part of the
> complete solution, but ..

By using bitmaps you are restricting yourself to at most a specific
number of capabilities and you don't get very fine grained security
anyway (instead of black and white you get shades of gray). You want a
process to have the least authority that is needed to get the job done
and you can't get that by having such a coarse grained security.

The right approach would be to make each object <-> action relationship
a capability that can be given to any entity in the system (ie you want
a true capability model). An example: you want a process to be able to
modify /etc/passwd. So you simply create a modify_etc_passwd capability
and delegate it to processes that you want to be able to modify the user
database. If you want some processes to be only able to read (but not
modify) the database, you create another capability, the read_etc_passwd
capability, if you want the process to be able to modify the kernel, you
give it the modify_kernel capability, and so on.

Notice that in a true capability model /etc/passwd is just another
object, same as (for example) your ~/.profile, so you could as well let
the _users_ create their own execute_~_.profile capability and delegate
it to other users (and even their own processes, selectively that is).
Carefull observers have probably already noticed that this model is
clearly superior to any form of ACLs since having a capability is
sufficient for the process to be granted the desired access. Besides
being very flexible, this model also simplifies and speeds up a lot of
things, and - considerably improves security.

> > > 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.
> >
> > Why is the capabilities mask for children needed at all? I would
> > assume that the init binary (for example) would be changed to do:
> > fork ();
> > /* Child */
> > rip_out_capabilities ();
>
> The thing I was thinking of was having a capability server that you could
> ask for some capability that the server for some reason wants to serialize
> completely. So the server would do something like:
>
> .. validate request and authorization ..
> sys_give_capability(CAPABILITY_XXXX, pid, NO_CHILD);
>
> and then the server would remember the "pid" and if something happens (a
> more important request for that capability comes in and takes precedence,
> for example) it could forcibly do a
>
> sys_remove_capability(CAPABILITY_XXXX, pid);
>
> and know that there is nobody in the system that has the capability XXXX
> any more (or maybe it has a list of pid's that have that capability, and
> it can maintain the list completely).

This is called revoking capabilities.

Maintaining the list, searching and taking away capabilities is not
efficient. It is much better to simply invalidate the capability and
create another one. When the process that holds the old, invalidated
capability claims the capability, the claim is refused since the
capability is no longer valid. Notice that even _having_ a list of
processes that hold a capability is inefficient since it takes up space.

Andrej

--
Andrej Presern, andrejp@luz.fe.uni-lj.si


-
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.101 / U:0.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site