From: Paul Moore <paul.moore@hp.com>
To: vyekkirala@TrustedCS.com
Cc: "'James Morris'" <jmorris@namei.org>,
"Stephen Smalley" <sds@tycho.nsa.gov>,
selinux@tycho.nsa.gov,
"Karl MacMillan" <kmacmillan@mentalrootkit.com>,
"Joshua Brindle" <method@manicmethod.com>
Subject: Re: [RFC] [PATCH 4/4] SELinux changes
Date: Wed, 19 Sep 2007 17:40:04 -0400 [thread overview]
Message-ID: <200709191740.04406.paul.moore@hp.com> (raw)
In-Reply-To: <009801c7fb03$2c298260$cc0a010a@tcssec.com>
On Wednesday, September 19 2007 5:22:24 pm Venkatesh Yekkirala wrote:
> > -----Original Message-----
> > From: James Morris [mailto:jmorris@namei.org]
> > On Wed, 19 Sep 2007, Stephen Smalley wrote:
> > > We thought we were eliminating the need for these per-packet
> > > per-node/netif checks by way of secmark, but I guess not if we are
> > > keeping secmark separate from labeled networking.
> >
> > The checks should only be made if labeled networking is active.
>
> Actually even when we aren't using labeled networking, we would
> want to prevent packets arriving on a top-secret interface from
> being forwarded onto a secret interface. So, the checks would be
> in order here as well.
[Sorry to be quiet on the patches but I'm still looking/thinking]
Just for clarification James, what is the motivation for making the permission
checks conditional? Performance? Compatibility?
Compatibility is an issue that we are going to have to deal with for both flow
control and peer label reconciliation. My current thinking is that we
introduce a new functionality version flag which is set by the policy at load
time and is used to determine code paths. It's similar to the compat_net
flag but more general purpose.
--
paul moore
linux security @ hp
--
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.
next prev parent reply other threads:[~2007-09-19 21:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-18 17:32 [RFC] [PATCH 4/4] SELinux changes Venkat Yekkirala
2007-09-19 14:18 ` Stephen Smalley
2007-09-19 21:12 ` James Morris
2007-09-19 21:22 ` Venkatesh Yekkirala
2007-09-19 21:40 ` Paul Moore [this message]
2007-09-19 22:52 ` James Morris
2007-09-19 23:20 ` Paul Moore
2007-09-20 14:42 ` Venkatesh Yekkirala
2007-09-20 15:31 ` Paul Moore
2007-09-20 18:30 ` Paul Moore
2007-09-19 21:20 ` Venkatesh Yekkirala
2007-09-19 21:51 ` Paul Moore
2007-09-21 20:14 ` Paul Moore
-- strict thread matches above, loose matches on Subject: below --
2007-09-20 18:50 Chad Hanson
2007-09-20 18:58 ` Paul Moore
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=200709191740.04406.paul.moore@hp.com \
--to=paul.moore@hp.com \
--cc=jmorris@namei.org \
--cc=kmacmillan@mentalrootkit.com \
--cc=method@manicmethod.com \
--cc=sds@tycho.nsa.gov \
--cc=selinux@tycho.nsa.gov \
--cc=vyekkirala@TrustedCS.com \
/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.