[apparmor] IPC syntax - again

[John Johansen]

On 07/01/2013 06:27 PM, Seth Arnold wrote:
> On Fri, Jun 28, 2013 at 01:57:27PM -0700, Tyler Hicks wrote:
>> [...]
>> So lets add another twist to the profile. The screen locker only locks.
>> It launches a screen saver application that displays mesmerizing 3D
>> pipes that rapidly grow in every direction. The screen locker must kill
>> the screen saver when a user presses a button or moves the mouse. It
>> does this over DBus by calling the screen saver's Kill method.
>>
>> /usr/bin/screenlocker {
>>   signal receive kill label=/usr/bin/sessionmanager,
>>   dbus receive member=Kill label=/usr/bin/othersessionmanager,
>>   dbus send member=Kill label=/usr/bin/screensaver,
>> }
>>
>> member=Kill is an attribute of the peer in the third rule, despite member=Kill
>> being an attribute of the subject in the second rule. Confusing, but
>> manageable. DBus path, interface, and member shift between being a subject or
>> [...]
> 
> This example was perfect, and exactly what I needed to think through the
> problem a little bit further...
> 
> On Mon, Jul 01, 2013 at 05:35:32PM -0700, Tyler Hicks wrote:
>> [...]
>> What about only allowing a single permission per rule? That would ensure
>> that the rule is clearly written in the context of that permission and
>> there is no confusion.
>>
>> I understand that file rules allow multiple permissions but IPC rules
>> are considerably more complex, IMO.
> 
> And this solution is very nearly perfect.
> 
> I think it might be a bit too strict, since we can allow (again, TCP)
> "bind", "listen", and "accept" on a (port, address) without any
> confusion. The confusion comes when "connect" is added to the list.
> 
its not the connect that adds the confusion, its any permission that
deals with the message/channel/peer. Basically any perm where peering
could have benefit

> Of course, it'll be a rare program where it makes sense to put bind,
> listen, and accept in different profiles. For the majority of programs,
uh really?

Having a socket created and bound, and then passed off to handle accept
isn't that uncommon. Admittedly more common is having the accept handled
in the same place and passing off sockets that should only be read/written.

Whether we want to make a distinction between create, bind, and accept
is a separate question (I would say yes) but I think wrong to conflate
that issue with this.

> all three permissions could be bundled into a 'server' synonym. Perhaps
I really don't like that

> we keep the rule "one permission per IPC rule" and let this synonym
I don't care for that either

> be the short-hand way around three separate rules for the typical TCP
> server program.
> 
> It's less clear to me what we should do with "use" (ability to send or
> receive on a socket but not have permission to bind, listen, accept, or
> connect -- useful for e.g. confining a CGI script so that it can use the
> existing connection but cannot accept new connections while running and
> thus 'hijack' a website). Probably "use", "send", and "receive" (for
> UDP-like protocols) should be on their rules.
> 
> I really like the simplicity of one permission per rule. IPC is
its not simpler, it adds another restriction to the language for one set
of rules that doesn't exist for other classes of rules already

  file, mount, 

> complicated enough and smaller bites are useful for understanding what
> a policy means.
> 
sure there are times when breaking things down make sense, and there
are times forcing such behavior just leads to redundancy that takes
away