[Apparmor-dev] armoring the network access

[John Johansen]

On Mon, Sep 03, 2007 at 03:05:01PM +0300, Markku Savela wrote:
> 
> > Hmmm. I don't have any other ideas. The security significance of a
> > network rule is so context dependent.
> > 
> >     * "Can accept from" is much more dangerous from the internet than
> >       from some restricted address, but that's likely beyond vim's
> >       parsing ability, and we don't yet have addresses in this release.
> >     * "Can initiate connection" is perfectly safe in a client (Firefox)
> >       and very dangerous in a server (Apache) but how would vim know
> >       which a profile is?
I would debate that, but it is certainly more safe than your server
doing it.
> >     * ... etc. etc.
> 
> I'm jumping into middle of discussion, so I might be expressing
> opinions that have already been discussed to the death, but here is
> some jumble of thoughts ....
> 
hehe thanks for sticking your neck out and welcome to the discussion,
we don't mind rehashing semantics, or getting feedback.  There is
always the chance that we have missed something or given less weight to
something than some one else, and it is important to take everything
into consideration so we can get it right.

> From the discussion fragments I get impression (perhaps incorrectly),
> that planned AppArmor network model is at least partially leaning to
> the direction of examining each packet and verifying whether the
> packet originator or receiver has a right to this packet?
> 
True, this is partly due to kernel implementation and partly to do
with how sockets get shared and policy gets reloaded.

> To me this seems to be totally different model than AppArmor uses for
> file access: AppArmor verifies the access rights on file operations
> relating to opening and manipulating complete files as objects. It
> does not concern itself with each individual write or read operation,
> it relies on the kernel to work correctly after access bits have been
> set for it.
> 
Well actually it does mediate reads and writes, but this mediation is
only triggered under certain circumstances, and there is debate
of exactly what semantics those circumstances should be.  However one
of them is when an open file gets passed to a new process at which
point the sharing has to be validated.

> AppArmor on network operations could follow the same model:
> concentrate on protecting the socket opening and binding processes,
> and (in most cases) don't worry about individual packets. Assume the
> kernel does its job correct.
> 
AppArmor will where possible prevent opening and binding to sockets
which works well for sending data, but we also want to be able
to mediate data based on where it came from, which can require
mediation of packets.  Connection requests can be mediated so
that a new socket isn't setup but with udp packets, they are
just delievered straight to the socket.

> All network connects can be checked (and denied if needed) on socket
> connect. The destination address is known and kernel does not allow it
> to be changed for that socket (right?).
> 
For connected sockets yes, but udp does not have to be connected.

> However, I'm not yet familiar enough with Linux networking, to know
> whether LSM networking hooks are in such place that the actual target
> interface is already known for the hook, thus the following rule may
> prove problematic, if information is not available
> 
The networking hooks are problematic in several ways, not the least
of which some of them are in interrupt context so your only choice
is to label the packet.

>   tcp_connect to 10.0.0.17/16:50-100 via eth1,
> 
> The server sockets just need to be checked on bind time (in
> general). I would expect most common profile requirement for the
> servers would be simply stating what ports the server can listen, like
> for a generic web server
> 
>   tcp_accept to 0/0:80,
> 
> I'm not quite sure to what "from" and "to" refer -- the confusion
> comes whether looking at incoming or outgoing packet -- for that
> reason, at least some implementations of IPSEC policies normally use
> terminology "local" (address/port) and "remote" (address/port), which
> maker rules same and clear for incoming and outgoing packets. I would
> write above rule as
> 
>       tcp_accept local 0/0:80,
> 
yes, I prefer local and remote too,  

> Anyway, this would just verify on bind time that the local port is
> 80. Things do get trickier, if you need to limit the service to
> specific interface. The following already does rather good
> 
>   tcp_accept local 10.0.0.17/32:80
> 
> because it would only accept connects to a specific configured
> address. To keep all checking in bind time, this rule would require
> that application actually binds to specific address and bind would be
> denied otherwise (other option, which I'm not too sure about, would be
> for AppArmor hook implicitly do the specific binding, if application
> left it open, but deny operation if any other address is used).
> 
> Outgoing unconnected sockets (datagrams) do pose a problem. There is
> not much to check at bind time (except the source port). If there are
> limitations for outgoing packets, each send operation needs to be
> checked for destination.
> 
yep, it just a matter of where you do the checking, making AppArmor
specific code, exporting existing kernel code, or letting the
existing kernel code do it.

Since we are trying for upstream acceptance that influences our
design decisions heavily.

> Concerning outgoing packets (or remote addresses or ports) in general,
> I don't see actual address ranges very important here. Use of address
> ranges probably is just indirect way of controlling what users really
> want have a say: is this application allowed to talk a) only on
> loopback, b) some local network or c) to internet.
> 
> There are two basic reasons why such limits might be desired by the
> user:
> 
>   1) information security (e.g. I want my web server only be
>      accessible to local network, or I only want this application to
>      talk locally, and not "call home" :-)
> 
>   2) communication cost. Use of some links actually cost money to the
>      user and they don't want some random application to generate huge
>      bill to them (for example, internet connection could be via
>      expensive GPRS connection).
> 
> One could try to say, that a rule like
> 
>   tcp_connect to 10.0.0.17/16:50-100 via eth1,
> 
> could satisfy the requirement. But, I think there might be problems,
> with mobile devices, eth1 could at one place be just local lan or
> wireless and free, but at other times incur cost. Interface names may
> not always be the best. How do make a generic profile to for a
> specific application? Interface names can vary from host to host!
> 
yes, this is a problem and a generic profile wouldn't use an interface
name.  It would only be there so that if an admin want or needs
to tighten a profile down.

> Solving the problem might need changes to linux device driver
> API. There could be some way of asking the driver for some cost/access
> tag name, which could be used instead of interface name (or use sysfs
> / udev in some ingenious way).
> 
> What I would like to express, is a rule:
> 
>   tcp_connect to anywhere via "no-cost-interface"
> 
> or allow costly connect, but limit the bytes, time etc.
> 
Ugh, I would rather leave specifying restrictions based on these interfaces
to the admin, or device manufacture (linux embedded in phones, etc.)


regards
john
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://forge.novell.com/pipermail/apparmor-dev/attachments/20070903/eee5cff1/attachment.pgp