Messages in this thread | | | Date | Mon, 30 Mar 1998 09:30:56 +1000 | From | Richard Gooch <> | Subject | Re: Securelevel bitmap patch |
| |
Linus Torvalds writes: > > 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);
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.
> 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 ();
As things stand now, any trusted binary (i.e. suid-root) does much the same thing if needed (such as /bin/login), by calling setuid (), seteuid (). We don't have a child process "uid,euid,gid,egid,gid-saved-set" table either. So why do we need the child capabilities mask?
Regards,
Richard....
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |