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 facto
running 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 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.
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
