On 03/21/2014 06: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?
>
>> @@ -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?
>
heh yeah sorry I must have missed refreshing that. Notice the TOK_READBY
>> 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?
>
hrmm, yes no. Its from some messing I did play with the syntax (so deliberate)
but uhm got dropped and I missed it here (so not deliberate)
>> +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.
>
Again to do with permission encoding. It will come
--
AppArmor mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
