All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joshua Brindle <method@manicmethod.com>
To: Jacques Thomas <jthomas@cs.purdue.edu>
Cc: KaiGai Kohei <kaigai@ak.jp.nec.com>, SE Linux <selinux@tycho.nsa.gov>
Subject: Re: Type boundaries: questions on the semantics / is the enforcement correct ?
Date: Tue, 08 Dec 2009 14:46:11 -0500	[thread overview]
Message-ID: <4B1EAD03.1040805@manicmethod.com> (raw)
In-Reply-To: <4B14934F.9050401@cs.purdue.edu>



Jacques Thomas wrote:
> KaiGai Kohei wrote:
>>>>> I also think we have one other a rough option.
>>>>> It simply applies type boundaries on only sources to restrict its privileges,
>>>>> and it does not apply any restrictions on target types.
>>>>>
>>>>>
>>>>>
>>>> Unless there is a clear use for bounds on targets, I would favor this
>>>> option. (The "rough" one :-) )
>>>> I see mostly room for confusion with the bounds on target types, because
>>>> of the contravariance issue.
>>>>
>>>>
>>> I can write and submit a patch along these lines. The patch is
>>> straightforward: I just have to remove the "dead" code.
>>>
>> Note that libsepol has an option which test type-boundary violations
>> in usermode just before policy load.
>> Also check check_avtab_hierarchy_callback() in libsepol/src/hierarchy.c.
>> (It is called when )
>>
>> Historically, this code delivered from hierarchy namespace support by
>> Joshua Brindle. I'd like to ask him what about this change.
>>
>>    MEMO: The hierarchy namespace support implicitly set up type-boundary
>>          on a couple of types. For example, if we defined httpd_t.cgi type,
>>          it is implicitly bounded by httpd_t type without TYPEBOUNDS.
>>
>> I also have not seen any case example which restrict target types by
>> the hierarchy namespace support. So, it seems to me we have no matter
>> to remove the "dead" code.
>>
>> Joshua, what's your opinion?

I agree. The purpose of the type hierarchy was to confine children
domains to a subset of their parents (or a subset of the parent domain
-> parent target). For example, this is allowed:

allow subject object: file read;
allow subject.child object.child: file read;

This was so that the parent didn't specifically have to have access to
the child, but could allow children to access it based on the fact that
the targets parent was accessible by the subjects parent. This was
mostly for 'container' types where a subject isn't really used on the
system and is only used as a container.

We thought about adding a container keyword to remove those container
types from the policy before it was built but after the hierarchy checks
were done but that wouldn't work anymore due to the hierarchy checks in
the kernel.

>>
>>
>>
>>> However, could someone please indicate me how I am supposed to test the
>>> patch ? In other words, is there a standardized testing procedure that I
>>> am unaware of ?
>>>
>> http://ltp.sourceforge.net/
>>
>> It also contains SELinux testcases including type boundary, but it also
>> does not contains a case of type boundary on target types.
>>
> 
> Kaigai, thank you for you detailed answer.
> 
> Joshua, I am waiting for your opinion.
> 
> Thank you both,
> Jacques
> 
> 

--
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:[~2009-12-08 19:46 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-08 19:24 Type boundaries: questions on the semantics / is the enforcement correct ? Jacques Thomas
2009-11-18  2:44 ` KaiGai Kohei
2009-11-19 16:07   ` Jacques Thomas
2009-11-30 18:40     ` Jacques Thomas
2009-12-01  1:02       ` KaiGai Kohei
2009-12-01  3:53         ` Jacques Thomas
2009-12-08 19:46           ` Joshua Brindle [this message]
2010-01-15 15:51           ` Stephen Smalley
2010-01-18 10:10             ` KaiGai Kohei
2010-01-20  4:25               ` [PATCH 1/2] selinux: remove dead code in type_attribute_bounds_av() KaiGai Kohei
2010-01-20 13:33                 ` Stephen Smalley
2010-01-20 16:29                   ` contents of /etc/selinux/<type>/contexts/users/* Hasan Rezaul-CHR010
2010-01-20 17:33                     ` Stephen Smalley
2010-01-21  6:00                   ` [PATCH 1/2] selinux: remove dead code in type_attribute_bounds_av() KaiGai Kohei
2010-01-21 14:08                     ` Stephen Smalley
2010-01-24 22:24                     ` James Morris
2010-01-20  4:26               ` [PATCH 2/2] libsepol: remove dead code in check_avtab_hierarchy_callback() KaiGai Kohei
2010-02-05  5:42                 ` KaiGai Kohei
2010-02-05 14:50                   ` Stephen Smalley
2010-02-09  6:46                     ` KaiGai Kohei
2010-02-16  2:36                       ` KaiGai Kohei
2010-02-16 15:25                         ` Stephen Smalley
2010-02-16 23:49                           ` KaiGai Kohei
2010-02-17 13:51                             ` Stephen Smalley
2010-02-19  7:33                               ` KaiGai Kohei
2010-02-19 15:20                                 ` Stephen Smalley
2010-03-01  2:43                                   ` KaiGai Kohei
2010-03-01 14:34                                     ` Stephen Smalley
2010-03-03  8:09                                       ` KaiGai Kohei
2010-03-04 16:01                                         ` Joshua Brindle
2010-03-04 16:24                                           ` Joshua Brindle
2010-03-05  0:39                                           ` KaiGai Kohei
2010-03-05 14:19                                             ` Joshua Brindle
2010-03-05 14:25                                               ` Stephen Smalley
2010-03-05 14:31                                                 ` Joshua Brindle
2010-03-08  6:56                                                   ` KaiGai Kohei
2010-03-08 15:27                                                     ` Joshua Brindle
2010-02-19 17:31                             ` Stephen Smalley
2010-02-21 22:09                             ` James Morris

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=4B1EAD03.1040805@manicmethod.com \
    --to=method@manicmethod.com \
    --cc=jthomas@cs.purdue.edu \
    --cc=kaigai@ak.jp.nec.com \
    --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.