[apparmor] IPC syntax - again

[Seth Arnold]

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.

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,
all three permissions could be bundled into a 'server' synonym. Perhaps
we keep the rule "one permission per IPC rule" and let this synonym
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
complicated enough and smaller bites are useful for understanding what
a policy means.

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20130701/830204b8/attachment.pgp>