All of lore.kernel.org
 help / color / mirror / Atom feed
From: david caplan <dac@tresys.com>
To: Paul Moore <paul@paul-moore.com>
Cc: "Christopher J. PeBenito" <cpebenito@tresys.com>,
	Stephen Smalley <sds@tycho.nsa.gov>,
	SELinux Mail List <selinux@tycho.nsa.gov>
Subject: Re: RFC: packet checks always on option
Date: Thu, 17 May 2012 11:31:03 -0400	[thread overview]
Message-ID: <4FB519B7.5010502@tresys.com> (raw)
In-Reply-To: <CAHC9VhTeBZX116mXvn+wA64Oo+5BgNwg1Zp+h_vAcDHDKva+7w@mail.gmail.com>

On 5/17/2012 10:42 AM, Paul Moore wrote:
> On Thu, May 17, 2012 at 10:06 AM, david caplan <dac@tresys.com> wrote:
>> On 5/15/2012 2:45 PM, Paul Moore wrote:
>>> On Tuesday, May 15, 2012 11:46:27 AM Christopher J. PeBenito wrote:
>>>> On 05/15/12 11:04, Paul Moore wrote:
>>>>> On Tuesday, May 15, 2012 10:47:25 AM Christopher J. PeBenito wrote:
>>>>>> On 05/15/12 10:13, Paul Moore wrote:
>>>>>>> See my earlier comments in this thread about being able to verify the
>>>>>>> correctness of the secmark labels.  This has always been my core concern
>>>>>>> with your argument: you are concerned about the ability for policy to
>>>>>>> control network traffic labeled via secmark, but you seem to ignore the
>>>>>>> issue that there is no mechanism to verify the correctness of the
>>>>>>> secmark labels.  Making strong guarantees about the ability to enforce a
>>>>>>> given policy without any assurance that the labels are correct seems a
>>>>>>> bit silly to me.
>>>>>>
>>>>>> Believe me, as a policy person, I'd never ignore labeling correctness.  I
>>>>>> don't think SECMARK rule correctness has anything to do with this
>>>>>> discussion, as this is about the mechanism/enforcement itself.
>>>>>
>>>>> Perhaps I'm reading the two sentences above wrong, perhaps I'm thinking
>>>>> about it wrong, or perhaps you didn't write them as intended; but the two
>>>>> sentences above seem to contradict each other in my mind.  I just don't
>>>>> see how you can have enforcement via labels without correct application
>>>>> of the labels themselves.
>>>>
>>>> Of course for a system to work right you need correct enforcement, correct
>>>> policy, and correct labeling.  My whole argument is about the enforcement.
>>>> If you have correct labeling and correct policy but wrong enforcement, its
>>>> still incorrect. I'm only trying to argue on the enforcement; label
>>>> correctness is important, just not for this discussion.
>>>
>>> My argument is that worrying about enforcement without demonstrating you've
>>> solved the labeling issue is pointless.  It is my opinion that the labels have
>>> to be correct before you can perform any worthwhile enforcement.
>>
>> I agree that worthwhile enforcement requires correct labels but I'm not
>> following how that relates to having a complete non-bypassable
>> mechanism.
> 
> Either way the security policy isn't enforced correctly.
> 

No, if there is no enforcement mechanism then the policy is 100% not
enforced. If there is an enforcement mechanism then there is some chance
that it is enforced correctly.

If you're running an SELinux system you have some faith that your
policy, including labeling, is correct and you (should) have an
expectation that access to any object defined in that policy is mediated.



--
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.

  reply	other threads:[~2012-05-17 15:31 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-08 16:58 RFC: packet checks always on option Christopher J. PeBenito
2012-05-10 20:02 ` Paul Moore
2012-05-14 12:52   ` Christopher J. PeBenito
2012-05-14 15:35     ` Paul Moore
2012-05-14 16:42       ` Chad Hanson
2012-05-14 20:54         ` Paul Moore
2012-05-14 17:17 ` Stephen Smalley
2012-05-14 17:22   ` Stephen Smalley
2012-05-14 21:15   ` Paul Moore
2012-05-15 13:24     ` Christopher J. PeBenito
2012-05-15 14:13       ` Paul Moore
2012-05-15 14:47         ` Christopher J. PeBenito
2012-05-15 15:04           ` Paul Moore
2012-05-15 15:46             ` Christopher J. PeBenito
2012-05-15 18:45               ` Paul Moore
2012-05-17 14:06                 ` david caplan
2012-05-17 14:42                   ` Paul Moore
2012-05-17 15:31                     ` david caplan [this message]
2012-05-17 16:51                       ` Paul Moore
2012-05-16  2:18           ` Daniel J Walsh

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=4FB519B7.5010502@tresys.com \
    --to=dac@tresys.com \
    --cc=cpebenito@tresys.com \
    --cc=paul@paul-moore.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.