On Mon, 11 Jun 2007, David Smith wrote: > (D) staprun.auth will need to disallow certain staprun.auth command-line > arguments, such as: Plus: - "-u USERNAME" (assuming you allow -c, otherwise it has no effect; on the other hand, its support in staprun can help to to make it possible to use -c via staprun.auth) - "-t PID" (or "-x PID") (you need to disallow this because it is virtually impossible to avoid race conditions when you check whether a user is allowed to mess with a certain running process; alternatively, you can allow it and make it a requirement for blessed scripts that authorized users can attach them to any running process without compromising the security of the system) On 11 Jun 2007, Frank Ch. Eigler wrote: > Actually, it doesn't. A setuid program can drop its privileges after > performing the root-only operations (module loading), and invoke the > rest of the normal commands as the real userid. Staprun has to keep root privileges to be able to unload the kernel module when it finishes. Moreover, the mere possesion of an open fd for the control channel seems to be dangerous enough to make staprun de facto running under euid 0 as long as it keeps the fd open (correct me if I am wrong). BTW1: staprun should close the file descriptors it uses internally (control fd, relayfs fds) when it executes the target program given by -c. BTW2: Let's suppose start_cmd() creates a process running under an unprivileged user. I think it can be killed (by the unprivileged user) before it gets SIGUSR1 and the system might recycle its pid. Therefore kill() in STP_START branch of stp_main_loop() is unsafe. On Mon, 11 Jun 2007, David Smith wrote: > Perhaps there is a merged approach. Keep staprun_auth a thin wrapper > around staprun, but change staprun to raise and lower privileges as > needed when inserting/removing modules, setting up relayfs, etc. This might work but be very careful when you do it while multiple threads are running. --Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ] "Resistance is futile. Open your source code and prepare for assimilation." -- Fedora-security-list mailing list Fedora-security-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-security-list
