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

[Jamie Strandboge]

On 06/24/2014 11:36 AM, Tyler Hicks wrote:
> On 2014-06-24 07:54:54, Jamie Strandboge wrote:
>> On 06/24/2014 06:34 AM, Christian Boltz wrote:
>>> Hello,
>>>
>>> Am Montag, 23. Juni 2014 schrieb Jamie Strandboge:
>>>>  - 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)
>>>
>>> Including these rule in the base abstractions looks like a good idea.
>>>
>>> However I don't like that we force policy authors to use deny rules (or 
>>> rebuild 90% of abstractions/base) if they don't want the signal and 
>>> ptrace rules.
>>>
>>> Things will get even more interesting if someone for example wants to 
>>> (only) allow
>>>   signal (receive) peer=unconfined set=("HUP")
>>>
>>> The result will be a profile with lots of deny rules (one for each 
>>> signal that is not HUP) or, optimized version, a deny rule with a very 
>>> big set=(...).
>>>
>>
>> The deny rule is one way to handle it; people can always update their base
>> abstraction for their site requirements.
>>
>>>
>>> IMHO it would be a good idea to split abstractions/base into
>>> - abstractions/base-files (basically the "old" abstractions/base)
>>> - abstractions/base-ptrace (ptrace rules from your patch)
>>> - abstractions/base-signal (signal rules from your patch)
>>>
>>> abstractions/base would then basically be:
>>>   #include <abstractions/base-files>
>>>   #include <abstractions/base-ptrace>
>>>   #include <abstractions/base-signal>
>>>
>>
>> I'm not sure how this would address your previous comment.
> 
> It would keep policy authors from having to rewrite abstractions/base.
> If they didn't want to include all of the base abstraction, they could
> pick and choose what they include. For example, they could include
> base-files and base-ptrace, but could opt out of base-signal.
> 
> FWIW, I'm not advocating for or against the idea. I'm just thinking out
> loud on what Christian's proposal would mean...
> 

I guess I wasn't clear

Sure, in this case they could keep base-files but they would either have to
copy/paste what they want from base-ptrace or modify it. They are still
copy/pasting or modifying, so I (currently) don't understand the advantage of
moving this out.

Put another way, having profiled quite a bit with ptrace and signal rules, I
really don't see why people wouldn't always take these except under exceptional
circumstances. The reciprocal rule can be useful at times, but is very
cumbersome in practice on a targeted policy system. Also, these were put into
'base' to ease upgrades for existing systems. Splitting them all out into
different files makes that hard. Sure, you could split them all out then have
base #include the split out files, but if you still want to change the default
then you still have to play with files in /etc. I guess I could see that if we
split them out, 'base' could #include them so that upgrades are handled and new
policy could select exactly what it wants, but that takes me back to my point
that policy writing without these additions becomes *highly* system-dependent
which is why they make sense for 'base' IMO.

The patch was ACKd and committed before Christian commented. If people want to
split them out, we can discuss that. If others want them removed, we can discuss
that. Before we do either, please spend some time profiling with signal and
ptrace rules so we are all talking about the same thing (that isn't a criticism
since I don't know if people have already done this or not, I'm just saying that
I personally didn't have any sort of feel for what was needed or not until we
took the signal/ptrace mediation in Ubuntu).

-- 
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/20140624/239c31f0/attachment.pgp>