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


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."


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