Enable security modules to distinguish reading of process state via
proc from full ptrace access by renaming ptrace_may_attach to
ptrace_may_access and adding a mode argument indicating whether only
read access or full attach access is requested.  This allows security
modules to permit access to reading process state without granting
full ptrace access.  The base DAC/capability checking remains unchanged.

Read access to /proc/pid/mem continues to apply a full ptrace attach
check since check_mem_permission() already requires the current task
to already be ptracing the target.  The other ptrace checks within
proc for elements like environ, maps, and fds are changed to pass the
read mode instead of attach.

In the SELinux case, we model such reading of process state as a
reading of a proc file labeled with the target process' label.  This
enables SELinux policy to permit such reading of process state without
permitting control or manipulation of the target process, as there are
a number of cases where programs probe for such information via proc
but do not need to be able to control the target (e.g. procps,
lsof, PolicyKit, ConsoleKit).  At present we have to choose between
allowing full ptrace in policy (more permissive than required/desired)
or breaking functionality (or in some cases just silencing the denials
via dontaudit rules but this can hide genuine attacks).

This version of the patch incorporates comments from Casey Schaufler
(change/replace existing ptrace_may_attach interface, pass access
mode), and Chris Wright (provide greater consistency in the checking).

Note that like their predecessors __ptrace_may_attach and
ptrace_may_attach, the __ptrace_may_access and ptrace_may_access
interfaces use different return value conventions from each other (0
or -errno vs. 1 or 0).  I retained this difference to avoid any
changes to the caller logic but made the difference clearer by
changing the latter interface to return a bool rather than an int and
by adding a comment ...
[ message continues ]

Looks better to me.


Casey Schaufler
casey@schaufler-ca.com
--

[ message continues ]

I personally would call them something like PTRACE_MODE_MONITOR and
PTRACE_MODE_CONTROL.  Though PTRACE_MODE_MONITOR probably means less
than _READ to most people, but they seem more consistent with being
ptrace flags.  But I'm not asking you to change them.

Overall the split makes sense.

In this particular case, would it be worthwhile to also split
check_mem_permission or pass it a mode bit?  Note that two of the

--

[ message continues ]

I was going to split up the mem checking, but when I noticed that
check_mem_permission() presently always requires current to already be
tracing the target process, I saw no point in distinguishing between the
different modes of access - they all effectively require full ptrace in
the first place.

The other case that might be nice to distinguish is readlink vs.
follow_link, as the latter potentially allows access to objects that
would otherwise be private to the target process (pipes, sockets) or
unreachable by current (files in directories not searchable by current),
as noted by Chris, but I'm not sure how helpful that will be in practice
because most if not all programs that access /proc/pid/fd at all end up
at least stat'ing the fd files even if they never open them, and thus
always hit follow_link.  But SELinux will check those attempts to stat
or open the files at least.

-- 
Stephen Smalley
National Security Agency

--

[ message continues ]