Need some security advice for systemtap

[David Smith]

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