Messages in this thread | | | Date | Sun, 29 Mar 1998 22:00:19 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: Securelevel bitmap patch |
| |
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 ..
> > 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).
Just as an example, maybe the "login" program would give the capability to anybody who logs in on the console, and it would know that whenever the login shell is exited (or killed), the capability to start a graphical session automatically goes away..
(And no, I don't know that this makes sense, but I can see it perhaps being a fairly useful set of semantics with no real downside to them: kind of a "close-on-exec" for privileges).
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |