Re: Need some security advice for systemtap
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Pavel Kankovsky wrote:
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)
I knew about '-u USERNAME'. We'll probably allow '-x PID' for authorized users because if they can look at the entire system there isn't any point in not allowing them to look at a single process.
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 factorunning under euid 0 as long as it keeps the fd open (correct me if I am wrong).
Yep, you are right.
BTW1: staprun should close the file descriptors it uses internally (control fd, relayfs fds) when it executes the target program given by -c.
Good idea, I'll work on that.
BTW2: Let's suppose start_cmd() creates a process running under anunprivileged user. I think it can be killed (by the unprivileged user) before it gets SIGUSR1 and the system might recycle its pid. Thereforekill() in STP_START branch of stp_main_loop() is unsafe.
Hmm. Got any ideas on how to fix this?
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.
I believe I see what you mean here - if one thread raises privilegs while another thread performs a security-sensitive operation, we've got a problem.
Thanks for your time. -- David Smith dsmith@xxxxxxxxxx Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) -- Fedora-security-list mailing list Fedora-security-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-security-list
[Home] [Fedora Legacy List] [Fedora Maintainers] [Fedora Desktop] [Red Hat 9 Bible] [Fedora Bible] [Fedora SELinux] [Big List of Linux Books] [Yosemite News] [Yosemite Photos] [KDE Users] [Coolkey] [Fedora Tools]