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.
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
