[apparmor] [patch 20/21] Add the ability to specify ptrace rules

[Jamie Strandboge]

On 03/21/2014 08:34 PM, Seth Arnold wrote:
> On Mon, Mar 17, 2014 at 04:29:30PM -0700, john.johansen at canonical.com wrote:
>> ptrace rules currently take the form of
>>
>>   ptrace [<ptrace_perms>] [<peer_profile_name>],
>>   ptrace_perm := read|trace|readby|tracedby
>>   ptrace_perms := ptrace_perm | '(' ptrace_perm+ ')'
>>
>> After having used the cross check (permission needed in both profiles)
>> I am not sure it is correct for ptrace.
> 
> Hrm, I'm liked the idea of the cross-check here for some time, but haven't
> actually lived with it yet. What doesn't work so well?
> 

I started playing with these today and found that chromium-browser is not
very selective on what it tries to ptrace. Ie, it seems to be walking /proc
trying to ptrace everything-- I guess it is looking for its parent....

First off, the cross-check is pretty painful and doesn't honor deny rules
the way I would expect. For example, chromium tries to 'ptrace read'
everything, so I added rules like this:

    ptrace (read) /usr/lib/chromium-browser/chromium-browser,
    ptrace (read) /usr/lib/chromium-browser/chromium-browser//chromium_browser_sandbox,
    ptrace (readby) /usr/lib/chromium-browser/chromium-browser//chromium_browser_sandbox,

    deny ptrace (read) unconfined,
    deny ptrace (read) /usr/bin/*,
    deny ptrace (read) /usr/lib/firefox/*,
    deny ptrace (read) /usr/lib/thunderbird/*,
    deny ptrace (read) /usr/lib/telepathy/*,
    # doesn't work
    #deny ptrace (read) /usr/lib/[^c][^h][^r][^o][^m]*,
    #deny ptrace (read) /usr/lib/[^c][^h][^r][^o][^m]**,
    #deny ptrace (read) /usr/lib/[^c][^h][^r][^o][^m]*/*,
    #deny ptrace (read) /usr/lib/[^c][^h][^r][^o][^m]*/**,

But the deny rules don't silence the readby rule. Eg, I have this rule:
    deny ptrace (read) /usr/bin/*,

and expected since it silenced the denial that the corresponding readby
rule would not be needed since the read was blocked. However, I get the
following in the log still with the above rule:

    apparmor="DENIED" operation="ptrace" profile="/usr/bin/rhythmbox"
    pid=10522 comm="chrome-sandbox" requested_mask="readby"
    denied_mask="readby"
    target="/usr/lib/chromium-browser/chromium-browser//chromium_browser_sandbox"

I'm on the fence about the utility of the *by rules. I guess I see the
thinking if you have something that is confined and you want to say that
only a specific profile can ptrace it. Would it make sense to leave the
cross check in place, but don't trigger if trace/read was denied? I think
that would make it less painful, at least in the case of chromium.

Note, I imagine with chromium-browser and oxide we are just going to allow:
  ptrace read,

since we have yama. Problem is, with doing that the cross check would
generate a ton of readby denials, which means all our profiles probably
also need:
  ptrace readby,

or perhaps
  deny ptrace (readby) /usr/lib/chromium-browser/chromium-browser//chromium_browser_sandbox,
  deny ptrace (readby) /path/to/oxide/sandbox,

Interestingly, once I set all the ptrace rules, chromium-browser doesn't run
properly. I'm not sure why yet. Still trying to sort this out...

-- 
Jamie Strandboge                 http://www.ubuntu.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20140324/7c2a39ae/attachment.pgp>