[Apparmor-dev] armoring the network access

[Crispin Cowan]

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?
>>     * ... 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 ....
>   
As JJ said, you are most welcome to join the discussion.

> 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?
>
> 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.
>   
The interest in packets is because some traffic is connection-oriented,
and some traffic is connectionless datagrams.

For TCP traffic, the semantics actually is mostly about mediating
connections.

> 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.
>   
Yes, it does. This is definitely true for datagrams. If the policy is
connection-oriented, then it is possible the enforcement can skip packet
inspection, but just as with file access, revalidation may have to
happen if a connection is passed from one process to another.

> 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.
>   
I disagree. Consider the network access policy for a web server:

    * can accept inbound connections to ports 80 and 443, from any IP
      address
    * can initiate outbound connections, but *only* to 10.1.2.3.4 which
      is our backend database server
    * can not send datagrams at all (unless it is streaming media or
      something)

You notably don't want the web server initiating connections to public
IP addresses, because that is how a worm would spread.

> 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" :-)
>   
That is another good reason, but that is more than information security;
it also defends the web server from public attack.

However, this is at least as easy to do with a classic firewall as it is
with AppArmor, so I don't see it as very useful.

>   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).
>   
It's not really about cost. AppArmor is a very poor tool to use for
traffic shaping.

> 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!
>   
You're right. As JJ wrote, the "eth1" specification is for a local admin
to use, not for a policy shipped with the distro.

> 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"
>   
I would like for AppArmor to be able to express a policy with respect to
"internal" and "external" interfaces, but the semantics of where a given
network interface goes is really hard to assess from inside the Linux
box, so I suspect this wish of mine will remain a pipe dream for a while.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com
	AppArmor Chat: irc.oftc.net/#apparmor