help me please

[Ilmar S. Habibulin]

I disided to forward this to trustedbsd-discuss at .

On Thu, 27 Sep 2001, Robert Watson wrote:

> > > Assign additional labels to struct socket, which would treat the socket as
> > > an "object".  setsockopt() could then be used by appopriately privileged
> > > applications to modify those labels (which would default to matching those
> > > in the creating ucred).  Delivery to and from the socket would be based on
> > > these labels (a label for "send", and a label or label range to match
> > > "receive").  When delivering a packet to the TCP socket, the receive label
> > > range would be compared with the incoming label to see if it was in the
> > > range.
> > That would be label convertion, and i don't think, that it is right. The
> > process has one label, socket - another, and this would represent
> > BLM-violating information flow. IMHO. The process IS the subject and must
> > have the range of labels, equal to sockets of cause.
> The problem is that sockets may be shared by several processes, who may
> potentially have different labels.  For example, if the socket becomes
> stdin for several processes, and one of those processes has the privilege
> to modify its label.  I don't really mind where the label comes from
> (either the process or the socket) for out-going packets, however.  I've
> been looking at it in the following way:
>
> The socket is an object into which you put information.  When information
> is placed in the socket, it label becomes that of the socket: the decision
> to allow the process to put information in the socket is based on looking
> at the process's label and the socket's label.  This is a bit like a file,
> which can also be used for IPC: the file has a label, and the ability to
> add content to the file depends on the label of the process and the label
> of the file.  The ability of another process to later read the file
> depends on the socket label, and the label of that process, but not on the
> label of the original process.
> 
> Adding a label explicitly to the socket (as opposed to using the label
> cached in the credential that created the socket) allows you do do this
> properly, I think.  I.e., add
> 
> 	struct mac	so_label;
> 
> at the very least.  Maybe also make it a label range, which we currently
> don't support (but I'm working on).
Ok. I've made exactly as you described. My sockets have label and
read-write ops are checked. So i'll make the same thing in -current
implementation. My algoritms are:

I. TCP socket:

	first and second TCP handshake packets should have label. If they
	are unlabeled, then label them (mbufs) with some default label

	1) If LISTEN socket has non-equal label, then
		- incoming connect packet label should be equal to sockets
		label, if not - drop with reset;
		- socket accepts connection and sends SYN packet with
		label;
		- peer checks SYN packet label and if it is not equal to
		connecting socket label - drop with reset;
		- normal communication mode.
	2) If LISTEN socket has equal label (this should be set only by
	   priviledged process), then
		- incoming packet label becomes the label of the socket;
		- see 1).

	labels are sent using CIPSO type 1 tag (MLS labels).

II. UDP socket:

	each UDP packet should be labeled, if incoming packet has no
	label, it should be labeled with default label

	1) if recieving socket has non-equal label, then 
		- if label of packet do not match label of socket, then
		drop packet (multicast broadcast too)
		- else recieve it (put in queue)
	2) If recieving socket has equal label (priviledged process)
		- recieve any packet
		! but i don't know what to do with the label. One approach
		is to have some "last recieved label" storage, where
		incoming packet labels should be stored. Another - drop
		label (does portmap or nfsd needs label?). The third
		approach is to transfer label with the data while recv()
		call, but it is too complex imho.

> > > This would avoid the "treat the packet as a subject" problem, as well as
> > > the "treat a socket like a subject" problem.  There might be some places
> > No, i don't think that such problem exists. Process makes reads and writes
> > to the socket. Not socket does writes and reads to the process.
> 
> I guess I was considering it from this perspective: the socket is an
> object with a label.  Can the interface put the packet with label (a) into
> a socket with label (b).  But I think you're right: there is no problem
> here, because we can answer that question just fine, the important point
> is the process read from the socket.
> 
> > > where access control might be desirable (can the process in question send
> > > a packet with the socket label using its current label, can the process in
> > > question transfer a socket with this labeling to another process, when a
> > > process calls exec() can the resulting process inherit the socket, ... and
> > > related questions).
> > Well, again i don't think so. If we have non-priviledged processes, then
> > everything should go just fine. These issues appears while dealing with
> > priviledged processes. And they should be trusted, as a part of a kernel.
> > And behave correctly.
> 
> Ok, that sonds good.  This is like passing around low-port numbered
> sockets -- if a trusted process really wants to do that, that's fine.
> 
> > > What do you think of that idea?  I think that's similar to what was done
> > > in Trusted IRIX.
> > I have two emails from SGI network guru guy (as Richard said) about
> > possible ways of network packet labeling implementation. I can forward
> > them, if you is interested. His approach is basically the same as mine,
> > and mine is based on reading RFCs ;-).
> > One more thought - today i found Trusted Solaris 8 documentation in the
> > web. Have you any contacts with the sun guys? Through i do not like sun
> > and solaris, maybe they can share their variants of implementation?
> > 
> > PS. Enough for today, i'm going home ;-)
> 
> I've never really looked at Trusted Solaris, although I have looked a
> little at Argus's Pitbull product, which does much the same thing.  Casey
> at SGI, who runs their trusted systems group, previously worked for Sun
> and helped design Trusted Solaris, so I suspect much the same design is
> used there.
Yes, i think so too. They use some common approaches, but different
implementations, system calls, label encodings.


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