[apparmor] IPC syntax - again

[Ángel González]

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.


> 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
> 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).


>   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.