[apparmor] IPC syntax - again

[John Johansen]

On 07/10/2013 11:00 AM, Seth Arnold wrote:
> On Wed, Jul 10, 2013 at 01:35:35PM +0200, Ángel González wrote:
>> Replying to differenet mails:
>>> now what of abstract sockets? They are the same as unix domain but
>>> begin with \0. We could use this notation or chose an alternate way
>>> of expressing it.
>>>   network unix name=\0foo,
>>> or maybe
>>>   network unix abstract=foo,
>>>
>>
>> Use an @, ie.
>>  network unix @/tmp/.X11-unix/X0
>>
>> This is the syntax used on other places, such as netstat(1) output.
> 
> Oh, excellent. I'd overlooked this option entirely. This is perfect. :)
> 
>> I would use specific types for them, so you could for instance have
>> rules like:
>>  ftp server 0.0.0.0:21
>>  ftp connect ftp.ubuntu.com
>>  http get http://ftp.ubuntu.com/ubuntu/dists/saucy/*
> 
> I'd like to discourage DNS entries in AppArmor profiles. It's quite
> common for DNS responses to have only a subset of addresses that might
> be used for a service, and since some services publish TTLs of seconds
> and others publish TTLs of days, the complexity of writing a daemon to
> discover new addresses to allow -- and deciding when to disallow older
> addresses that are no longer published -- is simply staggering.
> 
> Yes, we could smack something together, but it'd always be wrong for
> someone. Maybe even slightly wrong for everyone. :)
> 
> Maybe we could write something in an unofficial-and-hope-it-is-helpful
> sort of way, to populate a <tunables/hostnames> configuration file...
> 
> IP addresses would be far less surprising.
> 
Well yes there is that, but it is easier for people to cope with. I think
we may be able to do something here with trusted helpers. The dns daemon
becomes a trusted helper, that looks up the requested address, checks
with policy and just like the trusted file picker extends the profile
for that ip address.

I don't think its viable for the compiler to be doing this all up front
but, I do think we could come up with something that while not perfect
could be adequate for many situations.

It wouldn't hurt logging to have some semantic tags tying a specific
address to a dns entry either.

As for protocols like ftp, I think getting the labeling and connsecmark
correct on a base rule would be hard and having a template that carries
intent, and reduces the chance for errors in policy makes a lot of sense.

Again not yet, we are still reworking the base system but once we get
that policy is just hard so anything we can do to help author and understand
policy makes a lot of sense.