This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Need some security advice for systemtap


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@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]