On Fri, 25 Jan 2002 08:20:23 EST, jmjonesat_private said: > Yes, thanks to this discussion I see that you are correct. My question > was based on the observation that different modules will use different > strategies and, until the target application is actually running, it is > not evident from examination of the permissions of various resources if it > will actually have permission to access anything. Shell scripts that use > code such as > > if test -r filename > then > ... > else > ... > fi > > no longer, necessarily, indicate that the file will be readable by > another application running as the same owner/group as the testing script. I originally thought that our esteemed colleage Mr Jones was good and thoroughly high on crack when he started this thread, but now I see the issue in question. autoconf/configure type programs often run tests to see if Feature X is available on the system - and good security practice says that you do your configure/make work as non-root, and only use root for the final install. Fortunately, on the syscall side, most autoconf tests only see if the function is in libc, and don't actually check if the function *works*. And for those functions that *do* test, a sane module will probably fail it in a way that the autoconf check says it's present. As far as /bin/test goes, I think the only security-sane way to do this is to run the configure step using whatever the module's equivalent of the SELinux 'newrole' command. The next big challenge will probably be getting software writers to stop saying "this needs to be set-UID root" or "this needs to be set-GID mail", and instead document "this needs to be able to send raw network packets" (for ping) or "this needs to bind to port 123 and set the system clock" (for NTP) or "this needs to be able to write a file in the /var/spool/mail directory" (for an SMTP mail delivery agent), so the sysadmin can create/find an appropriate role/class to restrict the module at runtime. /Valdis
This archive was generated by hypermail 2b30 : Fri Jan 25 2002 - 06:09:21 PST