From: Paul Moore <paul.moore@hp.com>
To: "Mikel L. Matthews" <mikel@argus-systems.com>
Cc: James Morris <jmorris@namei.org>,
netdev@vger.kernel.org, linux-security-module@vger.kernel.org,
selinux@tycho.nsa.gov, James Morris <jmorris@redhat.com>,
Stephen Smalley <sds@tycho.nsa.gov>
Subject: Re: [RFC 0/4] NetLabel
Date: Fri, 26 May 2006 12:15:51 -0400 [thread overview]
Message-ID: <447729B7.4060702@hp.com> (raw)
In-Reply-To: <44772824.6090505@argus-systems.com>
Mikel L. Matthews wrote:
> Paul Moore wrote:
>>James Morris wrote:
>>>On Thu, 25 May 2006, Paul Moore wrote:
>>>
>>>>This patch introduces a new kernel feature designed to support labeled
>>>>networking protocols such as RIPSO and CIPSO. These protocols are required to
>>>>interoperate with existing "trusted" operating systems such as Trusted
>>>>Solaris.
>>>
>>>A few initial comments.
>>>
>>>- Did you decide that you definitely need to verify labels on fragments?
>>>
>>>I can see the code's been added to do that, but wonder about a comment
>>>made during earlier discussion that mislabeled fragments could only come
>>>from a misbehaving trusted system. What is the threat model here?
>>>
>>
>>This is one part of the patch that I really don't have a strong feeling
>>for either way. There was some concern on the LSM list that not
>>checking the fragment options might be an issue so I added some code to
>>check the fragment options. Personally I think we are probably okay
>>without it as the un-autenticated/un-verified nature of these labeling
>>protocols more or less requires either a trusted network/hosts.
>>
>>If the community decides that this check is not required then I can
>>simply drop all of the changes in ip_fragment.c.
>
> If you state you are labeling session packets (tcp or udp), that would
> lead one to believe all packets are labeled (including fragments). Based
> on our past evaluations I don't think non-labeled fragments would make
> it through an evaluation if CIPSO/RIPSO were part of the TOE/security
> Target.
>
Outgoing fragment *should* be labeled correctly assuming the Linux base
network stack does the right thing (I haven't tested this yet). The
issue we are discussing here is what to do about incoming packets where
the fragments are not consistently labeled.
--
paul moore
linux security @ hp
next prev parent reply other threads:[~2006-05-26 16:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-25 20:06 [RFC 0/4] NetLabel Paul Moore
2006-05-25 20:58 ` Stephen Hemminger
2006-05-25 21:14 ` Paul Moore
2006-05-26 0:06 ` James Morris
2006-05-26 15:30 ` Paul Moore
2006-05-26 16:02 ` James Morris
2006-05-26 16:34 ` Paul Moore
2006-05-26 18:56 ` James Morris
2006-05-26 16:09 ` Mikel L. Matthews
2006-05-26 16:15 ` Paul Moore [this message]
2006-05-26 16:20 ` Mikel L. Matthews
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=447729B7.4060702@hp.com \
--to=paul.moore@hp.com \
--cc=jmorris@namei.org \
--cc=jmorris@redhat.com \
--cc=linux-security-module@vger.kernel.org \
--cc=mikel@argus-systems.com \
--cc=netdev@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).