On 03/21/2014 08:34 PM, Seth Arnold wrote: > On Mon, Mar 17, 2014 at 04:29:30PM -0700, [email protected] 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/
signature.asc
Description: OpenPGP digital signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
