[apparmor] [PATCH] policy updates for ptrace and signal mediation

[Steve Beattie]

On Mon, Jun 23, 2014 at 02:07:12PM -0500, Jamie Strandboge wrote:
> 
> I thought I sent these ages ago, but alas, I did not. Sorry.
> 
> Attached are two patches:
> 
>  - base-abstraction-ptrace-ipc.patch: adds policy to the base abstraction that
>    is basically required on systems using targeted policy. Namely:
>    - Allow reciprocal ptrace readby to everyone (requires peer unconfined or to
>      ptrace read to us)
>    - same for ptrace tracedby
>    - allow us to ptrace read ourselves
>    - receive all signals from unconfined
>    - allow us to signal ourselves
>    - allow sending and receiving "exists" (for pid existence)
>  - dnsmasq-libvirtd-signal-ptrace.patch: allow libvirtd to signal and ptrace us
> 
> Both have been used in Ubuntu and are in our latest stable and development
> releases (I did add a fix for LP: #1333377[1] that isn't in Ubuntu yet, but
> found in practice it is needed quite often). With these changes to the base
> abstraction, we found we had to do only minimal changes to shipped policy.
> 
> [1]https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1333377
> 
> -- 
> Jamie Strandboge                 http://www.ubuntu.com/

> Description: Adjust base abstraction for ptrace and signal mediation
> 
> Acked-By: Jamie Strandboge <jamie at canonical.com>
> 
> === modified file 'profiles/apparmor.d/abstractions/base'
> --- profiles/apparmor.d/abstractions/base	2013-04-09 01:11:43 +0000
> +++ profiles/apparmor.d/abstractions/base	2014-06-23 18:56:50 +0000
> @@ -103,6 +103,27 @@
>    # glibc malloc (man 5 proc)
>    @{PROC}/sys/vm/overcommit_memory r,
>  
> +  # Allow other processes to read our /proc entries, futexes, perf tracing and
> +  # kcmp for now
> +  ptrace (readby),
> +
> +  # Allow other processes to trace us by default (they will need 'trace' in
> +  # the first place). Administrators can override with:
> +  #   deny ptrace (tracedby) ...
> +  ptrace (tracedby),

Would these two make more sense for peer=unconfined and
peer=@{profile_name}? Or is the intent to rely on the peer needing
"ptrace read" and "ptrace trace" permissions and not require both
profiles be modified?

> +  # Allow us to ptrace read ourselves
> +  ptrace (read) peer=@{profile_name},
> +
> +  # Allow unconfined processes to send us signals by default
> +  signal (receive) peer=unconfined,
> +
> +  # Allow us to signal ourselves
> +  signal peer=@{profile_name},
> +
> +  # Checking for PID existence is quite common so add it by default for now
> +  signal (receive, send) set=("exists"),

Ah, sending kill(PID, 0), right.
Acked-by: Steve Beattie <steve at nxnw.org> for at least the 4 rules above.

>    # Workaround https://launchpad.net/bugs/359338 until upstream handles stacked
>    # filesystems generally. This does not appreciably decrease security with
>    # Ubuntu profiles because the user is expected to have access to files owned
> 

> Author: Jamie Strandboge <jamie at canonical.com>
> Subject: dnsmasq profile updates for signals and ptrace from libvirtd
Acked-by: Steve Beattie <steve at nxnw.org>

> Index: ipc-fixes-and-improvements/profiles/apparmor.d/usr.sbin.dnsmasq
> ===================================================================
> --- ipc-fixes-and-improvements.orig/profiles/apparmor.d/usr.sbin.dnsmasq	2014-03-27 11:03:09.893804000 -0500
> +++ ipc-fixes-and-improvements/profiles/apparmor.d/usr.sbin.dnsmasq	2014-04-03 02:32:55.321315465 -0500
> @@ -25,6 +25,9 @@
>    capability net_raw,           # for DHCP server ping checks
>    network inet raw,
>  
> +  signal (receive) peer=/usr/sbin/libvirtd,
> +  ptrace (readby) peer=/usr/sbin/libvirtd,
> +
>    /etc/dnsmasq.conf r,
>    /etc/dnsmasq.d/ r,
>    /etc/dnsmasq.d/* r,

-- 
Steve Beattie
<sbeattie at ubuntu.com>
http://NxNW.org/~steve/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20140623/06457fd5/attachment.pgp>