change coming with maverick's 2.6.34-5 kernels

[Kees Cook]

Hi Clint,

On Tue, Jun 01, 2010 at 03:31:19PM -0700, Clint Byrum wrote:
> On Sun, 2010-05-30 at 22:03 -0700, Kees Cook wrote:
> > As discussed[1] at UDS, Maverick's kernel will include three changes that
> > are common to other security-hardened Linux distributions.  The intent
> > is to gain these additional protections for the by-default average
> > Ubuntu system:
> > 
> >  a) PTRACE of direct children only (protects credentials-of-the-past)
> <snip>
> > What this means for you if you don't change any of the defaults:
> > 
> >  a) Using "strace -p PID" and gdb's "attach" command will NOT work
> >     unless you are the root user (i.e. use "sudo strace -p PID ...")
> >     Running stuff with "strace" and "gdb" directly will work normally.
> > 
> 
> From an ops standpoint, this can actually make things less secure on
> 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.

Right, it's the choice of the full sysadmin to hand out "sudo" access;
this is what could make a system less secure, not the change to ptrace.
In the case of multi-user servers, it probably makes the most sense to
flip the sysctl back to the more permissive scope.

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

Wrappers may be prone to races where processes are changing uid,
doing forks, etc.  The kernel needs to be the thing doing the PTRACE
access checking.  Really, it seems like the kernel would need to grow
the idea of "semi privileged capabilities".  Right now, caps are kind
of all-or-nothing.

So, in the cases where general ptracing is needed, the best course of
action at the moment is to flip the sysctl to zero.  In maverick gdb,
strace, and ltrace will report the following if they encounter EPERM on a
PTRACE_ATTACH attempt:

 Could not attach to process.  If your uid matches the uid of the target
 process, check the setting of /proc/sys/kernel/ptrace_scope, or try again
 as the root user.  For more details, see /etc/sysctl.d/10-ptrace.conf

And 10-ptrace.conf says:

 # The PTRACE system is used for debugging.  With it, a single user process
 # can attach to any other dumpable process owned by the same user.  In the
 # case of malicious software, it is possible to use PTRACE to access
 # credentials that exist in memory (re-using existing SSH connections,
 # extracting GPG agent information, etc).
 #
 # A PTRACE scope of "0" is the more permissive mode.  A scope of "1" limits
 # PTRACE only to direct child processes (e.g. "gdb name-of-program" and
 # "strace -f name-of-program" work, but gdb's "attach" and "strace -fp $PID"
 # do not).  The PTRACE scope is ignored when a user has CAP_SYS_PTRACE, so
 # "sudo strace -fp $PID" will work as before.  For more details see:
 # https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace
 #
 # In general, PTRACE is not needed for the average running Ubuntu system.
 # To that end, the default is to set the PTRACE scope to "1".  This value
 # may not be appropriate for developers or servers with only admin
 # accounts.
 kernel.ptrace_scope = 1

This should hopefully give enough direction to help.

-Kees

-- 
Kees Cook
Ubuntu Security Team