No subject

servers.

Currently I can give my DBA sudo access to sudo as the mysql user only,
and they can strace the running mysqld in production to see if it is
doing something it shouldn't. Sure they could seriously screw up mysqld
100 different ways, but at least they can't jump onto sshd and intercept
whatever is being typed, or rm -rf everything. The exposure is
contained.

I do think its certainly within reason to just say "you must have root
to debug on a live machine", but there are situations where that means
giving somebody the keys to the kingdom when they really just need a key
to their own room.

I like to do things that make it natural and intuitive to do things the
safest, simplest way. Unfortunately, what happens now when security
controls are extremely tight is most users just say "oh here let me give
you root". Even if there is a sysctl, if its not painfully obvious that
you need to turn it off, most of the time people will just fall back to
root.

> I'm curious what other people would recommend.  Once there's some
> consensus, I will go implement it.  :)
> 

Could we install a simple suid root wrapper around strace/gdb that you
install when you want "developer" strace/gdb?

It can still apply the rule that non root users can only attach to their
own processes, but it will then run attach as root to avoid having to
know that you need to run sudo to get it going. Workstations with
average users would simply never have this tool available, and so would
not be vulnerable to ptrace problems (not to mention that I believe the
use case indicated didn't involve actually using strace/gdb, but rather
malware using ptrace directly). 

As an admin, I'd be totally fine with having these tools available on my
servers by default, as they help solve problems without really reducing
security (assuming the suid root bit is kept tidy).

-C