[Apparmor-dev] Network definitions in profile

[Markku Savela]

ext John Johansen wrote:
> On Fri, Nov 30, 2007 at 02:40:11PM +0200, Markku Savela wrote:

>> socket_recvmsg
>>
>>   Socket recvmsg is useless -- it only indicates application is
>>   ready to receive data (datagram).
>>
> hmm, not useless but not important to what you propose.

As far as I can see from the code, "socket_recvmsg" is direct result
of application issuing a receive request (read, recv, recvmsg). The
LSM call does not have any information of the received/pending data,
there may not even be any data queued for the socket at this
point. Thus, it cannot be used to check anything against profile,
except perphaps "is application allowed to read the socket".

> Hrmm, I am not fond of using the bind keyword (though I am more than
> willing to be convinced otherwise).  In the older design the binding
> information is there it is just implicit.  What I would like to see
> change from the older design is from, to becoming "local" and
> "remote" so it is easy to determine what is meant.  And then a
> subset of the full proposal could be used to obtain the binding
> information.

I leaned towards using the explicit "bind" keyword to avoid the
following "fuzzy" problem: using your connect/accept, you can end up
with following

  1) network tcp connect to #80 from #1025-65k,
  2) network tcp accept local #6660-6699

At the time of "bind", the call does not know whether the socket is
going to be used for accepting incoming connection or outgoing
connections. Which of the above lines will bind to port 6667 match
against?

If (1) is chosen, it is incorrect, if socket is actually used for
incoming connections (no port 80), and if (2) is chosen, it is
incorrect, if later connect to port 80 follows. Of course, some
correction might be done at later "connect" or even "listen".

We could say that "bind" LSM only checks the "accept" lines to solve
this, but then in the future extension, you might have

   1) network udp accept local #53 remote 10.0.0/8
   2) network udp accept #50-100

Should "bind to port 53" match first or second? It really does not
have information to accept (1) and if it does, it seems to give wrong
"assurance" (especially if profile lines include some flow labeling
tags in future).

If the "remote"-clause is not allowed in "accept", above can be
expressed as

   1) network udp connect remote 10.0.0/8 from #53
   2) network udp accept #50-100

And assume "bind" only checks (2). But, then accept would be a synonym
of my "bind" keyword, with no other functionality.

In conclusion, because I felt that "bind LSM hook" can only check
against very specific lines in profile, I leaned towards explicit
"bind" instead of generic "accept", which seemed give impression that
it can express more, but when you try to use is more generally, you
run into issues presented above.

I don't say that those issues are not solvable, but it was easier to
cop out with "bind", rather than try to lay out the rules for generic
"accept" lines...


---------------
Some minor notes on remaining texts..

> This makes the bind information implicit as part of the rules still
> leaves us open to do rules like,
> 
>   network tcp connect to #80 from #1025-65k,
> 
> for connections we can figure out the bind source allowed and have
> the pairing without relying on netfilter.

Just a note: this would seem to cover the automatic source port
assignment. However, in such case the connect LSM does not know the
source port (without explicit bind, the source port is still undefined
at that point). With above rule the connect LSM hook would have to
reject all outgoing HTTP connections (because they usually don't use
bind and the unspecified port would not match 1024-65k)

>> - could the algorithms used in file path matching utilized somehow
>>   (e.g. can the network profiles be turned into file path like
>>   constructs that can be processed and matched with existing
>>   functions within apparmor kernel module).
>>
> yes.  It requires some user side work, a lot of which I have been
> doing anyways to make the dfa code more general.  The data could be
> represented as an ordered string but it would be even better to
> treat it in a binary fashion so that the kernel doesn't need to
> build up a string to match against.

For the "string match" approach, the port range expression might be a
challenge (unless your DFA matching can include binary in range
operation for integers in the "match string"). Similarly, the network
prefix match could be problematic, if the prefix length is not
multiple of 8 bits.

-- 
Markku Savela