help me please
Ilmar S. Habibulin
ilmar at watson.org
Fri Sep 28 07:26:53 GMT 2001
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
- 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
More information about the trustedbsd-discuss