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. > 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). Hrm, I'm not necessarily sure we need to be doing packet inspection to determine GET vs POST vs PUT vs DELETE HTTP verbs. We can enforce that a client must talk with a proxy, and the proxy can be written to enforce HTTP verbs or allowed / denied resources. It just doesn't feel like AppArmor's place to look beyond packet headers. > > > 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. I've gone back and forth on a keyword to mean both af_inet and af_inet6. Having to double all the rules to allow ipv4 or ipv6 would be a touch irritating, but it is nicely explicit. Thanks
signature.asc
Description: Digital signature
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor