[apparmor] IPC syntax - again

[John Johansen]

On 07/10/2013 04:35 AM, Á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.
> 
yeah, thanks for pointing that out, its one of those things you know
but didn't think about until someone points it out

> 
>> File will be extended to support the
>>
>>   <prefix> file [<perm>] <path>,
> 
> Good. I find this syntax cleaner. :)
> 
> 
>>> One very useful AppArmor profile for FTP would prevent FTP "bounce"
>>> scanning:
>>>
>>> profile ftpd {
>>>    network inet stream (bind, listen, accept) subject=(port=21),
>>>    network inet stream (bind, listen, accept) subject=(port=20),
>>>    network inet stream (connect),
>>>    # deny access to internal hosts
>>>    deny network inet stream (connect) peer=(address4=192.168.0.0/16),
>>>    deny network inet6 stream (connect) peer=(address6=fe80::/64),
>>>    deny network inet6 stream (connect) peer=(address6=2001:db8::/32),
>>> }
>>>
>> Haha, again! Where are we going to stick those pesky permission
>>
>> So this will work with active ftp but not passive. Nor does it provide
>> a binding between the connect and the peer that did the initial connection
>>
>> Do I have a good suggested syntax for doing those things? Not yet just
>> saying this really isn't sufficient for ftp, at least in passive mode
>> as we need to be able to accept a connection on N>  1024 from the host
>> that made the initial connection to port 21.
>>
>> Some thing along the lines of (and no I am not proposing doing this)
>>    network inet stream (bind, list, accept) subject=(port=20) {
>>      network inet stream (bind, list, accept) peer=(address=@{peeraddress} port=@{peerport}+1)
>>      network inet stream (connect) peer=(address=@{peeraddress} port=@{peerport}+1)
>>    }
>>
>> yes tcp is an awful protocol, but that is one reason its interesting to
err make that ftp, sigh
>> look at.
>>
>> Is doing this with in the apparmor policy the correct place to do stuff
>> like this? I'm inclined to say no when we have the conntracker that
>> already has rules for dealing with ftp's weirdness.  And we could get
>> away with something like
>>
>>    network inet stream label=ftp_t connected,
>>
>> or some such.
> 
> 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/*
> 
> Those rules would currently alias a simple rule like "fetch anything on port 80" but could also transparently add a label with a magic name, or redirect the connection to a protocol-specific proxy (or even support a system switch so they have a different meaning when there is a company proxy).
> 
yes I'd like to get to where we can specify protocol specific or other custom
rules. But I am also hesitant to offer rules that we can't don't actually
offer mediation for. The
  http get http://ftp.ubuntu.com/ubuntu/dists/saucy/*
Looks like we are offering a lot more functionality than we currently can.

I understand the want to have a nice rule that lets you specify what you
want, and then compiles to what is actually supported. This way the
rule just works as new features get added, but I worry about the users
who miss the footnote of not actually supported at this time. Perhaps
a compiler warning about the reduction in mediation would be enough.

But for this pass we are trying to limit the work to a base line, think
of this as the first pass providing the rules that can be aliased too. Its
going to take us at least releases to finish up all the things we would
like to do with networking.

Extension wise I'd like to get where we have a template system that makes
it easy to extend the language, for either new externally supported types
or to provide rules like the protocol specific example above.

That way you could just include a template into your profile and start
using the new format instead of the compiler having to be updated.

> 
>>   network inet,   # all inet allowed
>>   inet,           # the inet keyword equivalent of network inet,
>>
>>   inet bind address=192.168.1.10,   # a finer grained inet rule
> 
> Will ‘inet’ mean af_inet and af_inet6 or only af_inet? I'm not fond on the abbreviation, but I understand rules would get quite long. Perhaps network could be abbreviated to "net" instead.
> 
inet is af_inet, they are auto generated from the address family entries in
header file.  Why af_ was stripped, I don't remember, but its something that
has been standard for years in apparmor.

Its possible we could support both af_inet and inet but we need to support
the abbreviated form.  And the intent of the new rule form is to remove the
need for network for specific address families that we offer better mediation
on by using the address family name as the keyword.

I'd like to keep the support address family keyword the same as what is
supported under network.

eg.

   network inet6,
   inet6 ...,

that still leaves the possibility of supporting af_inet, ... if that is what
people want to do


thanks for the feedback