On Mon, Mar 17, 2014 at 04:29:30PM -0700, john.johan...@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?
> @@ -470,6 +471,15 @@
> <DBUS_MODE,SIGNAL_MODE>{
> send { RETURN_TOKEN(TOK_SEND); }
> receive { RETURN_TOKEN(TOK_RECEIVE); }
> +}
> +
> +<PTRACE_MODE>{
> + trace { RETURN_TOKEN(TOK_TRACE); }
> + viewedby { RETURN_TOKEN(TOK_READBY); }
> + tracedby { RETURN_TOKEN(TOK_TRACEDBY); }
> +}
> +
> +<DBUS_MODE,SIGNAL_MODE,PTRACE_MODE>{
'viewedby' feels out of place; there's also no 'read' nor 'readby' here
but I'm not sure that matters?
> read { RETURN_TOKEN(TOK_READ); }
> write { RETURN_TOKEN(TOK_WRITE); }
> {OPEN_PAREN} {
> @@ -481,9 +491,11 @@
> }
> }
>
> -<MOUNT_MODE,DBUS_MODE,SIGNAL_MODE>{
> +<MOUNT_MODE>{
> {ARROW} { RETURN_TOKEN(TOK_ARROW); }
> +}
Was this intentional?
> +rules: rules opt_prefix ptrace_rule
> + {
> + if ($2.owner)
> + yyerror(_("owner prefix not allowed on ptrace rules"));
And again the question about 'owner', it isn't exactly redundant with
capability sys_ptrace, it still might be useful for root processes.
Thanks!
signature.asc
Description: Digital signature
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
