From: Venkat Yekkirala <vyekkirala@TrustedCS.com>
To: paul.moore@hp.com
Cc: jmorris@namei.org, netdev@vger.kernel.org, selinux@tycho.nsa.gov,
davem@davemloft.net, sds@tycho.nsa.gov, eparis@redhat.com
Subject: Re: Labeled Networking Requirements and Design (formerly RE: [PATCH 01/06] MLSXFRM: Granular IPSec associations for use in MLS environments)
Date: Tue, 27 Jun 2006 10:45:42 -0500 [thread overview]
Message-ID: <44A152A6.3060809@trustedcs.com> (raw)
In-Reply-To: <44A0684D.9080904@trustedcs.com>
> Keeping in mind (R1a), I wonder if it makes more sense for (OTBND1a) to take
> the label of the process/domain which sends the data to the socket? After
> all, the process/domain is the "origin" of the data.
Right. This is what "ends up" happening in the non-privileged case. In the
privileged multi-level process case, the label of the data has in fact been
established at the socket creation time itself, and here we are trusting the
privileged multi-level process with sending data out on the right socket with
the knowledge that the data would be labeled with the label of the socket.
> This seems to be
> particularly important in the case of fork()-then-exec() where you could have
> a socket created at a different context from the domain currently writing to
> it.
It would also help to remember that there are additional process-to-socket
controls (sendmsg, recvmsg) already in place in SELinux.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
WARNING: multiple messages have this Message-ID (diff)
From: Venkat Yekkirala <vyekkirala@trustedcs.com>
To: paul.moore@hp.com
Cc: jmorris@namei.org, netdev@vger.kernel.org, selinux@tycho.nsa.gov,
davem@davemloft.net, sds@tycho.nsa.gov, eparis@redhat.com
Subject: Re: Labeled Networking Requirements and Design (formerly RE: [PATCH 01/06] MLSXFRM: Granular IPSec associations for use in MLS environments)
Date: Tue, 27 Jun 2006 10:45:42 -0500 [thread overview]
Message-ID: <44A152A6.3060809@trustedcs.com> (raw)
In-Reply-To: <44A0684D.9080904@trustedcs.com>
> Keeping in mind (R1a), I wonder if it makes more sense for (OTBND1a) to take
> the label of the process/domain which sends the data to the socket? After
> all, the process/domain is the "origin" of the data.
Right. This is what "ends up" happening in the non-privileged case. In the
privileged multi-level process case, the label of the data has in fact been
established at the socket creation time itself, and here we are trusting the
privileged multi-level process with sending data out on the right socket with
the knowledge that the data would be labeled with the label of the socket.
> This seems to be
> particularly important in the case of fork()-then-exec() where you could have
> a socket created at a different context from the domain currently writing to
> it.
It would also help to remember that there are additional process-to-socket
controls (sendmsg, recvmsg) already in place in SELinux.
next prev parent reply other threads:[~2006-06-27 15:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-26 23:05 Labeled Networking Requirements and Design (formerly RE: [PATCH 01/06] MLSXFRM: Granular IPSec associations for use in MLS environments) Venkat Yekkirala
2006-06-26 23:05 ` Venkat Yekkirala
2006-06-27 0:29 ` James Morris
2006-06-27 0:29 ` James Morris
2006-06-27 1:53 ` Paul Moore
2006-06-27 1:53 ` Paul Moore
2006-06-27 15:45 ` Venkat Yekkirala [this message]
2006-06-27 15:45 ` Venkat Yekkirala
2006-06-27 15:47 ` Venkat Yekkirala
2006-06-27 15:47 ` Venkat Yekkirala
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44A152A6.3060809@trustedcs.com \
--to=vyekkirala@trustedcs.com \
--cc=davem@davemloft.net \
--cc=eparis@redhat.com \
--cc=jmorris@namei.org \
--cc=netdev@vger.kernel.org \
--cc=paul.moore@hp.com \
--cc=sds@tycho.nsa.gov \
--cc=selinux@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.