Messages in this thread | | | From | jmcmullan@linuxcar ... | Subject | Re: Capabilities | Date | 20 Feb 2000 15:33:15 GMT |
| |
Khimenko Victor <khim@sch57.msk.ru> wrote: >[snip snip] > (for example now apache start with UID=0 so it has all capabilities and > then with change of UID it'll drop all capabilities; in trusted system even > with change of UID capabilities will retain: UID==0 is not special in "trusted > Linux"). So system-wide option looks unavoidable :-((
Just because I'm a frick'n idiot, why can't we bind capability mask to UID/GIDs? That would solve a lot of the administration and ``what happens if we mount a FAT filesystem?'' issues, IMHO.
* UID/GID capability masks (/etc/capabilites?) would be loaded by /sbin/init. A user with the capability (CAP_SETUCAP?) could modify current mapping via /proc/sys/????/capabilty.
* The capabilities are only acquired on SUID or login. Ie r-xr-xr-x man man /usr/bin/man - No capabilties r-sr-xr-x net bin /usr/bin/ping - Capabilties of the ``net'' user r-xr-sr-x bin audio /usr/bin/play - Capabilties of the ``audio'' group
* Programs can _drop_ capabilties. If kernel support for capabities is diabled, or their UID/GID is not in the mapping table, the capability system call is a no-op.
* Allows for distributions that can turn on or off capability support easily. With no need to rewrite existing daemons/applications.
* No need to change any filesystems. This technique would work even on old Minix filesystems.
* Easy administration - just do the same ``look for files that are SUID and owned by this UID'' that we already do.
So what do ya'll think?
-- Jason McMullan, Senior Linux Consultant, Linuxcare, Inc. 412.422.8077 tel, 415.701.0792 fax jmcmullan@linuxcare.com, http://www.linuxcare.com/ Linuxcare. Support for the revolution.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |