i have packet labeling working prototype

Ilmar S. Habibulin ilmar at watson.org
Wed Sep 26 10:17:55 GMT 2001



On Tue, 25 Sep 2001, Robert Watson wrote:

> 
> On Tue, 25 Sep 2001, Ilmar S. Habibulin wrote:
> 
> > TCP connections now are monitored and i can make access control
> > desisions based on packet label. I used CISPO in IP header and mbuf
> > labeling (in m_pkthdr), proposed by Robert. It's simple to reimplement
> > it using IPSO(RIPSO), but IMHO IPSO(RIPSO) has limited abilities. 
> 
> Great news.  I'm in the process of updating the MAC code for post-KSE in
> FreeBSD 5.0-CURRENT, and hope to have a MAC system up and running again
> this afternoon.  I've also poked a little at the network stack issues for
> access control on out-going packets, and would be interested in knowing
> what approach you were taking.  In my most recent pass, I simply have
I did not touch chanel and physical layers. I've only read RFC 791, 793
and FIPS 188, and tryed to implement them. So i labeled only packets, not
interfaces. There is ip_dooptions(), which is used for CIPSO label
extraction from incoming packet and storing it in m->m_pkthdr.maclabel.
Then at the TCP level in LISTEN state code i made packet and socket label
compairing, like RFC 793 says (p.65). Except hacks to make root(0)
daemons recieve multilevel connection requests.

> checks at the top of the physical layer abstraction (ether_output() and
> others) to see whether the outgoing packet label in the mbuf is acceptable
> according to the labels on the interface.  I suspect I need a better
> abstraction for the "label range", and will look at that in the next
> couple of days.  The concern, of course, is that "label range" assumes the
> possibility of defining useful scopes of labels based on two endpoints,
> which is true of Biba and MLS, but not of more general policies such as
> TE.
Ye, that's a problem. I developed my code on the old 2.2 version with
fixed MAC label, so i have to include new flag for socket for network root
servers (like telnetd, ftpd, etc). But they also must be rewritten,
because telnetd (for ex.) uses useruser rights, while providing telnet
session. I don't know, why it was made so, but this allows to pass
information of any label with out any control (of labels).

One more thing - i've found socket labeling code in telnetd with ifdefs
for UNICOS (a Cray OS). Maybe these guys can help us too? This ifdefs were
present in 2-stable, they are absent in -current.

> I hope to post an updated patch within a day or two, and would like to get
> your IPSO changes integrated.  Given that we still lack a means for
No problem. I checked IP sources before making this pilot project - i hope
it would be easy to port my work, but only to IPv4. I have to examine IPv6
and IPSec.

> trusted applications to manage the labeling on sockets (TSIX, presumably,
> in the short term), we'll need to address that concern.  Right now, all
> labeling of packets in my implementation is implicit based on the
> credential bound to the socket at creation time.  This probably needs
> substantial adjustment.
It's easy to make socket relabeling with mac_set_fd() or setsockopt().

> > Now i'm trying to implement something over UDP. The problem is - absence
> > of any standards on UDP packets handling based on labels. So i have to
> > develop own algorithm. Maybe someone can share some infoemation with me
> > on that topic? 
> 
> I had assumed it would continue to be present in UDP as an IP option, but
> could be wrong.  Another thing I'd like to look at is picking up labeling
Yes, label is and IP option. But in case of TCP there is strict standard,
says that connection should only be established betwin two subjects if
their labels are equal. And in case of UDP there is no such stuff. at all.
:( SGI guys have implemented something, and their algorithm is intuitivly
undertanable. I'll try to make something like that.

> from IPsec tunnel endpoint properties: where a virtual interface is used
> for the tunnel endpoint, this should actually be pretty trivial, and might
> already work now (modulo lack of admin tools for labels on interfaces).
I suppose it is just another ifconfig flag or option. Or i missed
something?


To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message



More information about the trustedbsd-discuss mailing list