Packet labeling in RSBAC
ali valizadeh <[email protected]>
| Newsgroups | gmane.linux.rsbac |
|---|---|
| Message-ID | <[email protected]> |
Hi, I am researching on mac systems in a university. I have found many great subjects in rsbac and want to use it in a project. I asked two questions from rsbac mailing list last week, and many thanks to Amon for the answers. (the questions and answers attached) The questions were about rsbac network approach and packet labeling. Amon said that "rsbac does not yet support network packet labeling". In my project I want to label packets and support mac in network level. I found that selinux and smack do that using Cipso protocol. I want to extend rsbac to support packet labeling using Cipso. I have some questions: 1) How can I do that? 2) How can I use socket system calls to do that? 3) Which system calls should be modified? (syscall interception) 4) Will you have any idea to support packet labeling like selinux in the future? (Is it in your roadmap for the future?) Regards, Ali ________________________________ From: "[email protected]" <[email protected]> To: [email protected] Sent: Tue, November 17, 2009 2:30:02 PM Subject: rsbac Digest, Vol 46, Issue 2 Send rsbac mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://www.rsbac.org/mailman/listinfo/rsbac or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of rsbac digest..." Today's Topics: 1. Re: MAC labels (Amon Ott) (ali valizadeh) 2. Re: MAC labels (Amon Ott) (Amon Ott) ---------------------------------------------------------------------- Message: 1 Date: Mon, 16 Nov 2009 20:43:54 -0800 (PST) From: ali valizadeh <[email protected]> Subject: Re: [rsbac] MAC labels (Amon Ott) To: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset=iso-8859-1 Thanks to the post. It's very usefull. But, I want to transfer file and I want to have MLS (Multi Level Security) over the network. So, when a file with "Secret" label sent from one end to another, I want to?recive?that file with "Secret" label in another end point of the network. Does RSBAC have solution for packet labeling? ---------------------------------------------------------------------- Message: 1 Date: Sun, 15 Nov 2009 11:38:20 -0800 (PST) From: ali valizadeh <[email protected]> Subject: [rsbac] MAC labels To: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset=iso-8859-1 Hi, I?am trying?to transfer MAC labels over the network using IP packets. For this reason, I want to read the labels in kernel level. Would anyone help me to?do that? Regards, Ali ? ? ? ------------------------------ Message: 2 Date: Mon, 16 Nov 2009 08:51:07 +0100 From: Amon Ott <[email protected]> Subject: Re: [rsbac] MAC labels To: RSBAC Discussion and Announcements <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain;? charset="iso-8859-1" On Sunday 15 November 2009 wrote ali valizadeh: > I?am trying?to transfer MAC labels over the network using IP packets. For > this reason, I want to read the labels in kernel level. Would anyone help > me to?do that? RSBAC labels network items per connection end point. Each socket has a local and a remote end point, so labels are used for both ends independently. The current scheme looks up the default level of the remote end of the connection through template settings, based on protocol, address etc. This scheme could still be used as fallback, if no label has been received from remote. Explicitely set labels for one endpoint override the template values. This can be a problem with UDP, where the remote address and port can change with every packet. The current MAC implementation explicitely sets values for local endpoints, but relies on templates for remote. If you have the "struct socket *", labels are easy to read (look into rsbac/adf/mac/mac_main.c for examples). However, using sockets for identification means that you have to transfer the labels on transport level (OSI 4, TCP, UDP etc.), not on packet level (OSI 3, IP) like other systems do. For labels on TCP connections, using transport level has the advantage that both partners can even negotiate a common level for the connection at handshake time. Any solution for RSBAC should take this into account. Amon. -- http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22 ------------------------------ _______________________________________________ rsbac mailing list [email protected] https://www.rsbac.org/mailman/listinfo/rsbac End of rsbac Digest, Vol 46, Issue 1 ************************************ ------------------------------ Message: 2 Date: Tue, 17 Nov 2009 09:27:53 +0100 From: Amon Ott <[email protected]> Subject: Re: [rsbac] MAC labels (Amon Ott) To: RSBAC Discussion and Announcements <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset="iso-8859-1" On Tuesday 17 November 2009 wrote ali valizadeh: > Thanks to the post. It's very usefull. > But, I want to transfer file and I want to have MLS (Multi Level Security) > over the network. So, when a file with "Secret" label sent from one end to > another, I want to?recive?that file with "Secret" label in another end > point of the network. Does RSBAC have solution for packet labeling? No, it does not yet support network packet labeling. In my idea, the sending side should only agree to network link labels that fit to the file label, and the receiving side can only create the file with a correct label. Sending something, e.g. the file, over network is like copying it twice: First to the network link, then to the target file. If both ends are always in a secure state, then the information flow is always correct. Amon. -- http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22 ------------------------------ _______________________________________________ rsbac mailing list [email protected] https://www.rsbac.org/mailman/listinfo/rsbac End of rsbac Digest, Vol 46, Issue 2 ************************************