I would like to change the behavior of MCS label creations in directory.

I would like to change the behavior of MCS label creations in directory.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Currently if I create a directory labeled

etc_t:s0:c1

And with a process running as unconfined_t:s0-s0:c0.c1023 create a
file within the directory, the file gets created with the label
etc_t:s0.   I would like to change the behavior to creating the file
as etc_t:s0:c1.

That way an administrator could modify files within a sandbox and have
the files be labeled correctly.

I believe this behavior differs from MLS but believe this would be
what the admin expects.

Is changing this a kernel or policy issue?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk57kjMACgkQrlYvE4MpobO6GACgrZnzZl4OySYUkZATfl7RJPWb
z1YAn0m4wkHLWYWlR6urpuQ0tuGb+cdN
=uDm1
-----END PGP SIGNATURE-----

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

Re: I would like to change the behavior of MCS label creations in directory.

[Guido Trentalancia]

On Thu, 2011-09-22 at 15:53 -0400, Daniel J Walsh wrote:
> Currently if I create a directory labeled
> 
> etc_t:s0:c1
> 
> And with a process running as unconfined_t:s0-s0:c0.c1023 create a
> file within the directory, the file gets created with the label
> etc_t:s0.   I would like to change the behavior to creating the file
> as etc_t:s0:c1.
> 
> That way an administrator could modify files within a sandbox and have
> the files be labeled correctly.
> 
> I believe this behavior differs from MLS but believe this would be
> what the admin expects.
> 
> Is changing this a kernel or policy issue?

Should be a kernel issue. Sounds interesting.

Regards,

Guido


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

Re: I would like to change the behavior of MCS label creations in directory.

[Stephen Smalley]

On Thu, 2011-09-22 at 15:53 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Currently if I create a directory labeled
> 
> etc_t:s0:c1
> 
> And with a process running as unconfined_t:s0-s0:c0.c1023 create a
> file within the directory, the file gets created with the label
> etc_t:s0.   I would like to change the behavior to creating the file
> as etc_t:s0:c1.
> 
> That way an administrator could modify files within a sandbox and have
> the files be labeled correctly.
> 
> I believe this behavior differs from MLS but believe this would be
> what the admin expects.
> 
> Is changing this a kernel or policy issue?

That would be a kernel change, and it would have to be configurable so
that it can differ for MLS vs MCS.

-- 
Stephen Smalley
National Security Agency


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

Re: I would like to change the behavior of MCS label creations in directory.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/22/2011 04:31 PM, Stephen Smalley wrote:
> On Thu, 2011-09-22 at 15:53 -0400, Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> Currently if I create a directory labeled
>> 
>> etc_t:s0:c1
>> 
>> And with a process running as unconfined_t:s0-s0:c0.c1023 create
>> a file within the directory, the file gets created with the
>> label etc_t:s0.   I would like to change the behavior to creating
>> the file as etc_t:s0:c1.
>> 
>> That way an administrator could modify files within a sandbox and
>> have the files be labeled correctly.
>> 
>> I believe this behavior differs from MLS but believe this would
>> be what the admin expects.
>> 
>> Is changing this a kernel or policy issue?
> 
> That would be a kernel change, and it would have to be configurable
> so that it can differ for MLS vs MCS.
> 
It would seem that we should be able to state the behaviour in policy.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk57m0MACgkQrlYvE4MpobNoxgCg5xkSZKYxe6hvi8FPv+b3Qbck
IF0AnjkjLW5A/Y7wcTEYaxTJQEcc8im7
=WxYt
-----END PGP SIGNATURE-----

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

Re: I would like to change the behavior of MCS label creations in directory.

[Stephen Smalley]

On Thu, 2011-09-22 at 16:32 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 09/22/2011 04:31 PM, Stephen Smalley wrote:
> > On Thu, 2011-09-22 at 15:53 -0400, Daniel J Walsh wrote:
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >> 
> >> Currently if I create a directory labeled
> >> 
> >> etc_t:s0:c1
> >> 
> >> And with a process running as unconfined_t:s0-s0:c0.c1023 create
> >> a file within the directory, the file gets created with the
> >> label etc_t:s0.   I would like to change the behavior to creating
> >> the file as etc_t:s0:c1.
> >> 
> >> That way an administrator could modify files within a sandbox and
> >> have the files be labeled correctly.
> >> 
> >> I believe this behavior differs from MLS but believe this would
> >> be what the admin expects.
> >> 
> >> Is changing this a kernel or policy issue?
> > 
> > That would be a kernel change, and it would have to be configurable
> > so that it can differ for MLS vs MCS.
> > 
> It would seem that we should be able to state the behaviour in policy.

Yes, that was my meaning - allow the default labeling behavior be
configurable in policy.  Ideally for each field of the security context.
We already provide significant flexibility through type_transition and
range_transition rules, but not quite what you want here.  In effect,
you want the same default behavior for levels as we already have for
types, i.e. inherit from parent directory.  Meanwhile, I've seen others
who wanted inherit-from-creating-process for types.  So providing a
policy construct to specify the desired default for each context
component would be fine.  I think we've even discussed it before.

-- 
Stephen Smalley
National Security Agency


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

Re: I would like to change the behavior of MCS label creations in directory.

[Stephen Smalley]

On Thu, 2011-09-22 at 16:37 -0400, Stephen Smalley wrote:
> On Thu, 2011-09-22 at 16:32 -0400, Daniel J Walsh wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On 09/22/2011 04:31 PM, Stephen Smalley wrote:
> > > On Thu, 2011-09-22 at 15:53 -0400, Daniel J Walsh wrote:
> > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> > >> 
> > >> Currently if I create a directory labeled
> > >> 
> > >> etc_t:s0:c1
> > >> 
> > >> And with a process running as unconfined_t:s0-s0:c0.c1023 create
> > >> a file within the directory, the file gets created with the
> > >> label etc_t:s0.   I would like to change the behavior to creating
> > >> the file as etc_t:s0:c1.
> > >> 
> > >> That way an administrator could modify files within a sandbox and
> > >> have the files be labeled correctly.
> > >> 
> > >> I believe this behavior differs from MLS but believe this would
> > >> be what the admin expects.
> > >> 
> > >> Is changing this a kernel or policy issue?
> > > 
> > > That would be a kernel change, and it would have to be configurable
> > > so that it can differ for MLS vs MCS.
> > > 
> > It would seem that we should be able to state the behaviour in policy.
> 
> Yes, that was my meaning - allow the default labeling behavior be
> configurable in policy.  Ideally for each field of the security context.
> We already provide significant flexibility through type_transition and
> range_transition rules, but not quite what you want here.  In effect,
> you want the same default behavior for levels as we already have for
> types, i.e. inherit from parent directory.  Meanwhile, I've seen others
> who wanted inherit-from-creating-process for types.  So providing a
> policy construct to specify the desired default for each context
> component would be fine.  I think we've even discussed it before.

Here was the prior discussion:
http://marc.info/?l=selinux&m=129985320617740&w=2

For the range field, it is a little more complicated, as you might want
the low or the high level from either the source or the target.  Or even
a function of them, e.g. the lub.

-- 
Stephen Smalley
National Security Agency


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

Re: I would like to change the behavior of MCS label creations in directory.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/22/2011 04:42 PM, Stephen Smalley wrote:
> On Thu, 2011-09-22 at 16:37 -0400, Stephen Smalley wrote:
>> On Thu, 2011-09-22 at 16:32 -0400, Daniel J Walsh wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>> 
>>> On 09/22/2011 04:31 PM, Stephen Smalley wrote:
>>>> On Thu, 2011-09-22 at 15:53 -0400, Daniel J Walsh wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>> 
>>>>> Currently if I create a directory labeled
>>>>> 
>>>>> etc_t:s0:c1
>>>>> 
>>>>> And with a process running as unconfined_t:s0-s0:c0.c1023
>>>>> create a file within the directory, the file gets created
>>>>> with the label etc_t:s0.   I would like to change the
>>>>> behavior to creating the file as etc_t:s0:c1.
>>>>> 
>>>>> That way an administrator could modify files within a
>>>>> sandbox and have the files be labeled correctly.
>>>>> 
>>>>> I believe this behavior differs from MLS but believe this
>>>>> would be what the admin expects.
>>>>> 
>>>>> Is changing this a kernel or policy issue?
>>>> 
>>>> That would be a kernel change, and it would have to be
>>>> configurable so that it can differ for MLS vs MCS.
>>>> 
>>> It would seem that we should be able to state the behaviour in
>>> policy.
>> 
>> Yes, that was my meaning - allow the default labeling behavior
>> be configurable in policy.  Ideally for each field of the
>> security context. We already provide significant flexibility
>> through type_transition and range_transition rules, but not quite
>> what you want here.  In effect, you want the same default
>> behavior for levels as we already have for types, i.e. inherit
>> from parent directory.  Meanwhile, I've seen others who wanted
>> inherit-from-creating-process for types.  So providing a policy
>> construct to specify the desired default for each context 
>> component would be fine.  I think we've even discussed it
>> before.
> 
> Here was the prior discussion: 
> http://marc.info/?l=selinux&m=129985320617740&w=2
> 
> For the range field, it is a little more complicated, as you might
> want the low or the high level from either the source or the
> target.  Or even a function of them, e.g. the lub.
> 

	level_default file fromsource; == MLS;
	level_default file fromtarget; == MCS;

Anyone want to step forward and implement?  :^)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk58nz0ACgkQrlYvE4MpobNEOwCfa2zqNBphbJq85eGgcjR23oFv
01kAn0RMmnDdoCm5crtclLlgPJHWiNzE
=zQOR
-----END PGP SIGNATURE-----

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

Re: I would like to change the behavior of MCS label creations in directory.

[Stephen Smalley]

On Fri, 2011-09-23 at 11:01 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 09/22/2011 04:42 PM, Stephen Smalley wrote:
> > On Thu, 2011-09-22 at 16:37 -0400, Stephen Smalley wrote:
> >> On Thu, 2011-09-22 at 16:32 -0400, Daniel J Walsh wrote:
> >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >>> 
> >>> On 09/22/2011 04:31 PM, Stephen Smalley wrote:
> >>>> On Thu, 2011-09-22 at 15:53 -0400, Daniel J Walsh wrote:
> >>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >>>>> 
> >>>>> Currently if I create a directory labeled
> >>>>> 
> >>>>> etc_t:s0:c1
> >>>>> 
> >>>>> And with a process running as unconfined_t:s0-s0:c0.c1023
> >>>>> create a file within the directory, the file gets created
> >>>>> with the label etc_t:s0.   I would like to change the
> >>>>> behavior to creating the file as etc_t:s0:c1.
> >>>>> 
> >>>>> That way an administrator could modify files within a
> >>>>> sandbox and have the files be labeled correctly.
> >>>>> 
> >>>>> I believe this behavior differs from MLS but believe this
> >>>>> would be what the admin expects.
> >>>>> 
> >>>>> Is changing this a kernel or policy issue?
> >>>> 
> >>>> That would be a kernel change, and it would have to be
> >>>> configurable so that it can differ for MLS vs MCS.
> >>>> 
> >>> It would seem that we should be able to state the behaviour in
> >>> policy.
> >> 
> >> Yes, that was my meaning - allow the default labeling behavior
> >> be configurable in policy.  Ideally for each field of the
> >> security context. We already provide significant flexibility
> >> through type_transition and range_transition rules, but not quite
> >> what you want here.  In effect, you want the same default
> >> behavior for levels as we already have for types, i.e. inherit
> >> from parent directory.  Meanwhile, I've seen others who wanted
> >> inherit-from-creating-process for types.  So providing a policy
> >> construct to specify the desired default for each context 
> >> component would be fine.  I think we've even discussed it
> >> before.
> > 
> > Here was the prior discussion: 
> > http://marc.info/?l=selinux&m=129985320617740&w=2
> > 
> > For the range field, it is a little more complicated, as you might
> > want the low or the high level from either the source or the
> > target.  Or even a function of them, e.g. the lub.
> > 
> 
> 	level_default file fromsource; == MLS;
> 	level_default file fromtarget; == MCS;
> 
> Anyone want to step forward and implement?  :^)

Need to distinguish low vs high.  In MLS, you want to inherit the low
level of the source/subject/process.

Also, do you want the MCS behavior for all types or selectively?  For
example, if a svirt_t:s0:c256,c387 process creates a file in a :s0
directory (is that even possible?), do you really want that file to
be :s0?

-- 
Stephen Smalley
National Security Agency


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

Re: I would like to change the behavior of MCS label creations in directory.

[Guido Trentalancia]

On Fri, 2011-09-23 at 11:07 -0400, Stephen Smalley wrote:
> On Fri, 2011-09-23 at 11:01 -0400, Daniel J Walsh wrote:
> > >>>>> Currently if I create a directory labeled
> > >>>>> 
> > >>>>> etc_t:s0:c1
> > >>>>> 
> > >>>>> And with a process running as unconfined_t:s0-s0:c0.c1023
> > >>>>> create a file within the directory, the file gets created
> > >>>>> with the label etc_t:s0.   I would like to change the
> > >>>>> behavior to creating the file as etc_t:s0:c1.
> > >>>>> 
> > >>>>> That way an administrator could modify files within a
> > >>>>> sandbox and have the files be labeled correctly.
> > >>>>> 
> > >>>>> I believe this behavior differs from MLS but believe this
> > >>>>> would be what the admin expects.
> > >>>>> 
> > >>>>> Is changing this a kernel or policy issue?
> > >>>> 
> > >>>> That would be a kernel change, and it would have to be
> > >>>> configurable so that it can differ for MLS vs MCS.
> > >>>> 
> > >>> It would seem that we should be able to state the behaviour in
> > >>> policy.

[cut]

> Need to distinguish low vs high.  In MLS, you want to inherit the low
> level of the source/subject/process.
> 
> Also, do you want the MCS behavior for all types or selectively?  For
> example, if a svirt_t:s0:c256,c387 process creates a file in a :s0
> directory (is that even possible?), do you really want that file to
> be :s0?

My opinion is: yes/NO.

So in other words, my opinion is that a categorized process should
always been allowed to write to an uncategorized directory. And then
that the default label for anything created by a categorized process,
should definitely be categorized.

However, there is an issue. For example, a given SELinux user might have
access to more than one category. What would be the default category for
labeling files produced by that user ?

Regards,

Guido


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

Re: I would like to change the behavior of MCS label creations in directory.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/23/2011 12:06 PM, Guido Trentalancia wrote:
> On Fri, 2011-09-23 at 11:07 -0400, Stephen Smalley wrote:
>> On Fri, 2011-09-23 at 11:01 -0400, Daniel J Walsh wrote:
>>>>>>>> Currently if I create a directory labeled
>>>>>>>> 
>>>>>>>> etc_t:s0:c1
>>>>>>>> 
>>>>>>>> And with a process running as
>>>>>>>> unconfined_t:s0-s0:c0.c1023 create a file within the
>>>>>>>> directory, the file gets created with the label
>>>>>>>> etc_t:s0.   I would like to change the behavior to
>>>>>>>> creating the file as etc_t:s0:c1.
>>>>>>>> 
>>>>>>>> That way an administrator could modify files within
>>>>>>>> a sandbox and have the files be labeled correctly.
>>>>>>>> 
>>>>>>>> I believe this behavior differs from MLS but believe
>>>>>>>> this would be what the admin expects.
>>>>>>>> 
>>>>>>>> Is changing this a kernel or policy issue?
>>>>>>> 
>>>>>>> That would be a kernel change, and it would have to be 
>>>>>>> configurable so that it can differ for MLS vs MCS.
>>>>>>> 
>>>>>> It would seem that we should be able to state the
>>>>>> behaviour in policy.
> 
> [cut]
> 
>> Need to distinguish low vs high.  In MLS, you want to inherit the
>> low level of the source/subject/process.
>> 
>> Also, do you want the MCS behavior for all types or selectively?
>> For example, if a svirt_t:s0:c256,c387 process creates a file in
>> a :s0 directory (is that even possible?), do you really want that
>> file to be :s0?
> 
> My opinion is: yes/NO.
> 
> So in other words, my opinion is that a categorized process should 
> always been allowed to write to an uncategorized directory. And
> then that the default label for anything created by a categorized
> process, should definitely be categorized.
> 
> However, there is an issue. For example, a given SELinux user might
> have access to more than one category. What would be the default
> category for labeling files produced by that user ?
> 
> Regards,
> 
> Guido
> 
> 
> -- 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.
> 
> 

For MCS I would say the default is the process creates the file at the
level of the directory if it can, otherwise it gets permission denied.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk58wv4ACgkQrlYvE4MpobPOTACgrIceJ4NJd1+TKO7bARzngyUm
xj4AnjdOM6Gcc0g7BhvmxF2cEMDCGWH5
=M09/
-----END PGP SIGNATURE-----

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

Re: I would like to change the behavior of MCS label creations in directory.

[David Windsor]

On Fri, Sep 23, 2011 at 11:07 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:

<snip>

>>
>>       level_default file fromsource; == MLS;
>>       level_default file fromtarget; == MCS;
>>
>> Anyone want to step forward and implement?  :^)
>
> Need to distinguish low vs high.  In MLS, you want to inherit the low
> level of the source/subject/process.
>
> Also, do you want the MCS behavior for all types or selectively?  For
> example, if a svirt_t:s0:c256,c387 process creates a file in a :s0
> directory (is that even possible?), do you really want that file to
> be :s0?
>

Couldn't you use a range_transition in this case to specify an
exception to the default behavior for category inheritance?

AFAICS, using rules such as (user|role|type|level|range)_default,
we're only specifying default labeling behaviors for the different
fields of a context.  More specific *_transition rules can exist in
policy that should override any defaults defined elsewhere.

Thanks,
David

> --
> Stephen Smalley
> National Security Agency
>
>
> --
> 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.
>



-- 
PGP: 6141 5FFD 11AE 9844 153E  F268 7C98 7268 6B19 6CC9


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

Re: I would like to change the behavior of MCS label creations in directory.

[Stephen Smalley]

On Sat, 2011-09-24 at 18:05 -0400, David Windsor wrote:
> On Fri, Sep 23, 2011 at 11:07 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> 
> <snip>
> 
> >>
> >>       level_default file fromsource; == MLS;
> >>       level_default file fromtarget; == MCS;
> >>
> >> Anyone want to step forward and implement?  :^)
> >
> > Need to distinguish low vs high.  In MLS, you want to inherit the low
> > level of the source/subject/process.
> >
> > Also, do you want the MCS behavior for all types or selectively?  For
> > example, if a svirt_t:s0:c256,c387 process creates a file in a :s0
> > directory (is that even possible?), do you really want that file to
> > be :s0?
> >
> 
> Couldn't you use a range_transition in this case to specify an
> exception to the default behavior for category inheritance?
> 
> AFAICS, using rules such as (user|role|type|level|range)_default,
> we're only specifying default labeling behaviors for the different
> fields of a context.  More specific *_transition rules can exist in
> policy that should override any defaults defined elsewhere.

range_transition would only let you specify things like "When files are
created by a process with domain D in a directory with type T, the range
should be set to R.".  Not rules of the form "Files created by processes
in domain D1 should inherit their level from their creator while files
created by processes in domain D2 should inherit their level from the
parent directory."

-- 
Stephen Smalley
National Security Agency


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

Re: I would like to change the behavior of MCS label creations in directory.

[David Windsor]

On Tue, Sep 27, 2011 at 12:06 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Sat, 2011-09-24 at 18:05 -0400, David Windsor wrote:
>> On Fri, Sep 23, 2011 at 11:07 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>
>> <snip>
>>
>> >>
>> >>       level_default file fromsource; == MLS;
>> >>       level_default file fromtarget; == MCS;
>> >>
>> >> Anyone want to step forward and implement?  :^)
>> >
>> > Need to distinguish low vs high.  In MLS, you want to inherit the low
>> > level of the source/subject/process.
>> >
>> > Also, do you want the MCS behavior for all types or selectively?  For
>> > example, if a svirt_t:s0:c256,c387 process creates a file in a :s0
>> > directory (is that even possible?), do you really want that file to
>> > be :s0?
>> >
>>
>> Couldn't you use a range_transition in this case to specify an
>> exception to the default behavior for category inheritance?
>>
>> AFAICS, using rules such as (user|role|type|level|range)_default,
>> we're only specifying default labeling behaviors for the different
>> fields of a context.  More specific *_transition rules can exist in
>> policy that should override any defaults defined elsewhere.
>
> range_transition would only let you specify things like "When files are
> created by a process with domain D in a directory with type T, the range
> should be set to R.".  Not rules of the form "Files created by processes
> in domain D1 should inherit their level from their creator while files
> created by processes in domain D2 should inherit their level from the
> parent directory."
>
> --
> Stephen Smalley
> National Security Agency
>

I realize that the semantics of the two rules are different.  I'm
wondering about the precedence of *_default rules: given a policy in
which conflicting labels are calculated for a newly created object of
a certain type, do *_default rules take precedence?

For instance, suppose the following rules:

range_default D1_t file use_source;
range_transition D1_t T_t:file R;

The first rule specifies that newly created files by processes in the
D1_t domain should inherit the range of the source/creating process.
The second rule specifies that files created by a process in the D1_t
domain in a directory labeled T_t should have a range of R.  This
seems to create a conflict for deciding the range of files created by
processes labeled D1_t in a directory labeled T_t.

What should happen here?

I would think that the more specific range_transition rule, which
specifies both the type of the creating process and the type of the
parent directory, would dictate the labeling of the created file and
that the range_default rule specifies labeling in the default case.

-- 
PGP: 6141 5FFD 11AE 9844 153E  F268 7C98 7268 6B19 6CC9


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

Re: I would like to change the behavior of MCS label creations in directory.

[Stephen Smalley]

On Tue, 2011-09-27 at 12:50 -0400, David Windsor wrote:
> On Tue, Sep 27, 2011 at 12:06 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > On Sat, 2011-09-24 at 18:05 -0400, David Windsor wrote:
> >> On Fri, Sep 23, 2011 at 11:07 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> >>
> >> <snip>
> >>
> >> >>
> >> >>       level_default file fromsource; == MLS;
> >> >>       level_default file fromtarget; == MCS;
> >> >>
> >> >> Anyone want to step forward and implement?  :^)
> >> >
> >> > Need to distinguish low vs high.  In MLS, you want to inherit the low
> >> > level of the source/subject/process.
> >> >
> >> > Also, do you want the MCS behavior for all types or selectively?  For
> >> > example, if a svirt_t:s0:c256,c387 process creates a file in a :s0
> >> > directory (is that even possible?), do you really want that file to
> >> > be :s0?
> >> >
> >>
> >> Couldn't you use a range_transition in this case to specify an
> >> exception to the default behavior for category inheritance?
> >>
> >> AFAICS, using rules such as (user|role|type|level|range)_default,
> >> we're only specifying default labeling behaviors for the different
> >> fields of a context.  More specific *_transition rules can exist in
> >> policy that should override any defaults defined elsewhere.
> >
> > range_transition would only let you specify things like "When files are
> > created by a process with domain D in a directory with type T, the range
> > should be set to R.".  Not rules of the form "Files created by processes
> > in domain D1 should inherit their level from their creator while files
> > created by processes in domain D2 should inherit their level from the
> > parent directory."
> >
> > --
> > Stephen Smalley
> > National Security Agency
> >
> 
> I realize that the semantics of the two rules are different.  I'm
> wondering about the precedence of *_default rules: given a policy in
> which conflicting labels are calculated for a newly created object of
> a certain type, do *_default rules take precedence?
> 
> For instance, suppose the following rules:
> 
> range_default D1_t file use_source;
> range_transition D1_t T_t:file R;
> 
> The first rule specifies that newly created files by processes in the
> D1_t domain should inherit the range of the source/creating process.
> The second rule specifies that files created by a process in the D1_t
> domain in a directory labeled T_t should have a range of R.  This
> seems to create a conflict for deciding the range of files created by
> processes labeled D1_t in a directory labeled T_t.
> 
> What should happen here?
> 
> I would think that the more specific range_transition rule, which
> specifies both the type of the creating process and the type of the
> parent directory, would dictate the labeling of the created file and
> that the range_default rule specifies labeling in the default case.

The *_default rules would just replace the current hardcoded default
logic.  They would be overridden by any matching *_transition rules just
as the current hardcoded default logic is overridden by such rules.

-- 
Stephen Smalley
National Security Agency


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

Re: I would like to change the behavior of MCS label creations in directory.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/27/2011 12:06 PM, Stephen Smalley wrote:
> On Sat, 2011-09-24 at 18:05 -0400, David Windsor wrote:
>> On Fri, Sep 23, 2011 at 11:07 AM, Stephen Smalley
>> <sds@tycho.nsa.gov> wrote:
>> 
>> <snip>
>> 
>>>> 
>>>> level_default file fromsource; == MLS; level_default file
>>>> fromtarget; == MCS;
>>>> 
>>>> Anyone want to step forward and implement?  :^)
>>> 
>>> Need to distinguish low vs high.  In MLS, you want to inherit
>>> the low level of the source/subject/process.
>>> 
>>> Also, do you want the MCS behavior for all types or
>>> selectively?  For example, if a svirt_t:s0:c256,c387 process
>>> creates a file in a :s0 directory (is that even possible?), do
>>> you really want that file to be :s0?
>>> 
>> 
>> Couldn't you use a range_transition in this case to specify an 
>> exception to the default behavior for category inheritance?
>> 
>> AFAICS, using rules such as
>> (user|role|type|level|range)_default, we're only specifying
>> default labeling behaviors for the different fields of a context.
>> More specific *_transition rules can exist in policy that should
>> override any defaults defined elsewhere.
> 
> range_transition would only let you specify things like "When files
> are created by a process with domain D in a directory with type T,
> the range should be set to R.".  Not rules of the form "Files
> created by processes in domain D1 should inherit their level from
> their creator while files created by processes in domain D2 should
> inherit their level from the parent directory."
> 

I think this is a different more advanced language construct, that
frankly I don't care about right now.  Implement it in CIL.
I have a problem I need to implement in F17/F18 time frame in order
for it to make RHEL7.

I only need to change the default for MCS to from
level_default file fromsource; == MLS;

to
level_default file fromtarget; == MCS;

I can not wait for the theoretical best fix that never comes.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6CEjwACgkQrlYvE4MpobNN/gCghV2LwrfGce50FdX7Iel0Z8pO
1IoAn3Vf7sXxz9qFsEnpoZQT6yIcjVUH
=sOyu
-----END PGP SIGNATURE-----

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

Re: I would like to change the behavior of MCS label creations in directory.

[Daniel J Walsh]

[-- Attachment #1: Type: text/plain, Size: 918 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

<snip>

Eric and I have come up with the following syntax for this behaviour.

default_trans level dir_file_class_set parent;
default_trans user dir_file_class_set process;
default_trans role file parent;

We have developed a patch to checkpolicy that will process this
syntax, although it does nothing with it yet, need a patch for libsepol...

We have made these commands optional and I am placing them in the
policy/mcs file.  Default will be current behavior.


ifdef(`enable_mcs',`
default_trans level dir_file_class_set parent;

#
# Define sensitivities
#
# MCS is single-sensitivity.

gen_sens(1)

...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6YW/sACgkQrlYvE4MpobNlHACgqYKr4T3Bi5tp4cPb0ee5mw3q
I2UAn2trAI2BXOGu+JAbSx2RBNPuAvpd
=MWrk
-----END PGP SIGNATURE-----

[-- Attachment #2: checkpolicy.patch --]
[-- Type: text/plain, Size: 6778 bytes --]

diff --git a/checkpolicy/policy_define.c b/checkpolicy/policy_define.c
index 1bf669c..7ec64aa 100644
--- a/checkpolicy/policy_define.c
+++ b/checkpolicy/policy_define.c
@@ -327,6 +327,39 @@ int define_initial_sid(void)
 	return -1;
 }
 
+int define_default_trans(int component, int from)
+{
+	char *id;
+	ebitmap_t e_tclasses;
+	class_datum_t *cladatum;
+
+	if (pass == 1) {
+		while ((id = queue_remove(id_queue)))
+			free(id);
+		return 0;
+	}
+
+	ebitmap_init(&e_tclasses);
+	while ((id = queue_remove(id_queue))) {
+		if (!is_id_in_scope(SYM_CLASSES, id)) {
+			yyerror2("class %s is not within scope", id);
+			return -1;
+		}
+		cladatum = hashtab_search(policydbp->p_classes.table, id);
+		if (!cladatum) {
+			yyerror2("unknown class %s", id);
+			return -1;
+		}
+		if (ebitmap_set_bit(&e_tclasses, cladatum->s.value - 1, TRUE)) {
+			yyerror("Out of memory");
+			return -1;
+		}
+		free(id);
+	}
+
+	return 0;
+}
+
 int define_common_perms(void)
 {
 	char *id = 0, *perm = 0;
diff --git a/checkpolicy/policy_define.h b/checkpolicy/policy_define.h
index 92a9be7..2c881e1 100644
--- a/checkpolicy/policy_define.h
+++ b/checkpolicy/policy_define.h
@@ -13,6 +13,14 @@
 #define TRUE 1
 #define FALSE 0
 
+enum dt_enum {
+	DT_USER,
+	DT_ROLE,
+	DT_LEVEL,
+	DT_PROCESS,
+	DT_PARENT,
+};
+
 avrule_t *define_cond_compute_type(int which);
 avrule_t *define_cond_pol_list(avrule_t *avlist, avrule_t *stmt);
 avrule_t *define_cond_te_avtab(int which);
@@ -52,6 +60,7 @@ int define_role_types(void);
 int define_role_attr(void);
 int define_roleattribute(void);
 int define_filename_trans(void);
+int define_default_trans(int componnt, int from);
 int define_sens(void);
 int define_te_avtab(int which);
 int define_typealias(void);
diff --git a/checkpolicy/policy_parse.y b/checkpolicy/policy_parse.y
index 49ac15f..86aa574 100644
--- a/checkpolicy/policy_parse.y
+++ b/checkpolicy/policy_parse.y
@@ -143,6 +143,9 @@ typedef int (* require_func_t)();
 %token POLICYCAP
 %token PERMISSIVE
 %token FILESYSTEM
+%token DEFAULT_TRANS
+%token PROCESS
+%token PARENT
 
 %left OR
 %left XOR
@@ -157,10 +160,10 @@ base_policy             : { if (define_policy(pass, 0) == -1) return -1; }
                           classes initial_sids access_vectors
                           { if (pass == 1) { if (policydb_index_classes(policydbp)) return -1; }
                             else if (pass == 2) { if (policydb_index_others(NULL, policydbp, 0)) return -1; }}
-			  opt_mls te_rbac users opt_constraints 
+			  default_trans_rules opt_mls te_rbac users opt_constraints 
                          { if (pass == 1) { if (policydb_index_bools(policydbp)) return -1;}
 			   else if (pass == 2) { if (policydb_index_others(NULL, policydbp, 0)) return -1;}}
-			  initial_sid_contexts opt_fs_contexts opt_fs_uses opt_genfs_contexts net_contexts opt_dev_contexts
+			  initial_sid_contexts opt_fs_contexts opt_fs_uses opt_genfs_contexts net_contexts opt_dev_contexts 
 			;
 classes			: class_def 
 			| classes class_def
@@ -176,6 +179,23 @@ initial_sid_def		: SID identifier
 			;
 access_vectors		: opt_common_perms av_perms
 			;
+default_trans_rules     : default_trans_def
+                        | default_trans_rules default_trans_def
+                        |
+                        ;
+default_trans_def	: DEFAULT_TRANS USER names PROCESS ';'
+			{if (define_default_trans(DT_USER, DT_PROCESS)) return -1;}
+			| DEFAULT_TRANS ROLE names PROCESS ';'
+			{if (define_default_trans(DT_ROLE, DT_PROCESS)) return -1;}
+			| DEFAULT_TRANS LEVEL names PROCESS ';'
+			{if (define_default_trans(DT_LEVEL, DT_PROCESS)) return -1;}
+			| DEFAULT_TRANS USER names PARENT ';'
+			{if (define_default_trans(DT_USER, DT_PARENT)) return -1;}
+			| DEFAULT_TRANS ROLE names PARENT ';'
+			{if (define_default_trans(DT_ROLE, DT_PARENT)) return -1;}
+			| DEFAULT_TRANS LEVEL names PARENT ';'
+			{if (define_default_trans(DT_LEVEL, DT_PARENT)) return -1;}
+			;
 opt_common_perms        : common_perms
                         |
                         ;
@@ -353,7 +373,7 @@ cond_rule_def           : cond_transition_def
 			| require_block
 			{ $$ = NULL; }
                         ;
-cond_transition_def	: TYPE_TRANSITION names names ':' names identifier filename ';'
+cond_transition_def	: TYPE_TRANSITION names names ':' names identifier '\"' filename '\"' ';'
                         { $$ = define_cond_filename_trans() ;
                           if ($$ == COND_ERR) return -1;}
 			| TYPE_TRANSITION names names ':' names identifier ';'
@@ -391,7 +411,7 @@ cond_dontaudit_def	: DONTAUDIT names names ':' names names ';'
 			{ $$ = define_cond_te_avtab(AVRULE_DONTAUDIT);
                           if ($$ == COND_ERR) return -1; }
 		        ;
-transition_def		: TYPE_TRANSITION  names names ':' names identifier filename ';'
+transition_def		: TYPE_TRANSITION  names names ':' names identifier '\"' filename '\"' ';'
 			{if (define_filename_trans()) return -1; }
 			| TYPE_TRANSITION names names ':' names identifier ';'
                         {if (define_compute_type(AVRULE_TRANSITION)) return -1;}
@@ -753,6 +773,8 @@ nested_id_element       : identifier | '-' { if (insert_id("-", 0)) return -1; }
                         ;
 identifier		: IDENTIFIER
 			{ if (insert_id(yytext,0)) return -1; }
+                        | PROCESS
+			{ if (insert_id(yytext,0)) return -1; }
 			;
 path     		: PATH
 			{ if (insert_id(yytext,0)) return -1; }
diff --git a/checkpolicy/policy_scan.l b/checkpolicy/policy_scan.l
index a61e0db..e7bdf9f 100644
--- a/checkpolicy/policy_scan.l
+++ b/checkpolicy/policy_scan.l
@@ -219,6 +219,12 @@ h2 |
 H2				{ return(H2); }
 policycap |
 POLICYCAP			{ return(POLICYCAP); }
+process |
+PROCESS				{ return(PROCESS); }
+parent |
+PARENT				{ return(PARENT); }
+default_trans |
+DEFAULT_TRANS			{ return(DEFAULT_TRANS); }
 permissive |
 PERMISSIVE			{ return(PERMISSIVE); }
 "/"({alnum}|[_\.\-/])*	        { return(PATH); }
@@ -227,9 +233,8 @@ PERMISSIVE			{ return(PERMISSIVE); }
 {digit}{1,3}(\.{digit}{1,3}){3}    { return(IPV4_ADDR); }
 {hexval}{0,4}":"{hexval}{0,4}":"({hexval}|[:.])*  { return(IPV6_ADDR); }
 {digit}+(\.({alnum}|[_.])*)?    { return(VERSION_IDENTIFIER); }
-\"({alnum}|[_\.\-])+\"		{ return(FILENAME); }
 {alnum}*                        { return(FILENAME); }
-\.({alnum}|[_\.\-])*	        { return(FILENAME); }
+\.({alnum}|[_\.\-])+	        { return(FILENAME); }
 {letter}+([-_\.]|{alnum})+      { return(FILENAME); }
 ([_\.]){alnum}+                 { return(FILENAME); }
 #line[ ]1[ ]\"[^\n]*\"		{ set_source_file(yytext+9); }
@@ -253,6 +258,7 @@ PERMISSIVE			{ return(PERMISSIVE); }
 "-" |
 "." |
 "]" |
+"\"" |
 "~" |
 "*"				{ return(yytext[0]); } 
 .                               { yywarn("unrecognized character");}

Re: I would like to change the behavior of MCS label creations in directory.

[Christopher J. PeBenito]

On 10/14/11 11:57, Daniel J Walsh wrote:
> Eric and I have come up with the following syntax for this behaviour.
> 
> default_trans level dir_file_class_set parent;

I think we want this to be "range" instead of "level", since the field is actually a range.

> default_trans user dir_file_class_set process;
> default_trans role file parent;

Isn't there a better set of tokens than this?  Why not make it default_user, default_role, default_type, and default_range?  Creating an object doesn't really imply a transition, so "trans" seems misleading.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

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

Re: I would like to change the behavior of MCS label creations in directory.

[David Windsor]

My client truncated my earlier message.

Is per-object granularity sufficient, or would a tuple of
(user/role/type, object) be a better key for indexing these rules?
This makes sense for the role and type fields of a context, but I'm
not so sure about the user field.

Examples:

default_user NetworkManager_t dir_file_class process;
default_role NetworkManager_t dir_file_class process;
default_type NetworkManager_t dir_file_class process;

I'm just unsure that per-object granularity is sufficient.  Thoughts?

Thanks,
David

On Tue, Oct 18, 2011 at 8:58 AM, David Windsor <dwindsor@gmail.com> wrote:
> "Christopher J. PeBenito" <cpebenito@tresys.com> wrote:
>>
>> On 10/14/11 11:57, Daniel J Walsh wrote:
>> > Eric and I have come up with the following syntax for this behaviour.
>> >
>> > default_trans level dir_file_class_set parent;
>>
>> I think we want this to be "range" instead of "level", since the field is
>> actually a range.
>>
>> > default_trans user dir_file_class_set process;
>> > default_trans role file parent;
>>
>> Isn't there a better set of tokens than this?  Why not make it
>> default_user, default_role, default_type, and default_range?  Creating an
>> object doesn't really imply a transition, so "trans" seems misleading.
>>
>> --
>> Chris PeBenito
>> Tresys Technology, LLC
>> www.tresys.com | oss.tresys.com
>
> Also, do we want to add the ability to specify a source type for default
> transitions so that transitions can be controlled with more granularity than
> on a per-object basis? For instance:
>
> default_user http



-- 
PGP: 6141 5FFD 11AE 9844 153E  F268 7C98 7268 6B19 6CC9


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

Re: I would like to change the behavior of MCS label creations in directory.

[Stephen Smalley]

On Tue, 2011-10-18 at 18:07 -0400, David Windsor wrote:
> My client truncated my earlier message.
> 
> Is per-object granularity sufficient, or would a tuple of
> (user/role/type, object) be a better key for indexing these rules?
> This makes sense for the role and type fields of a context, but I'm
> not so sure about the user field.
> 
> Examples:
> 
> default_user NetworkManager_t dir_file_class process;
> default_role NetworkManager_t dir_file_class process;
> default_type NetworkManager_t dir_file_class process;
> 
> I'm just unsure that per-object granularity is sufficient.  Thoughts?

We're trying to introduce the ability to configure the fallback default
for labeling behavior when no *_transition rule matches.
Per-object-class should be sufficient for that purpose.  If we want to
introduce more general _transition rules we can do that separately.

-- 
Stephen Smalley
National Security Agency


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

Re: I would like to change the behavior of MCS label creations in directory.

[Joshua Brindle]

Christopher J. PeBenito wrote:
> On 10/14/11 11:57, Daniel J Walsh wrote:
>> Eric and I have come up with the following syntax for this behaviour.
>>
>> default_trans level dir_file_class_set parent;
>
> I think we want this to be "range" instead of "level", since the field is actually a range.
>
>> default_trans user dir_file_class_set process;
>> default_trans role file parent;
>
> Isn't there a better set of tokens than this?  Why not make it default_user, default_role, default_type, and default_range?  Creating an object doesn't really imply a transition, so "trans" seems misleading.
>

I agree with Chris. This will actually let you make things not transition by 
default so _trans is misleading. Further, "process" shouldn't be a token since 
it is an object class (you couldn't actually parse policy with Eric's patches 
could you?). I don't like "parent" as a token either, and SELinux doesn't know 
anything about processes and parents anyway. SDS's suggestions a while back are 
more appropriate IMO, since SELinux does know what source and target are.

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

Re: I would like to change the behavior of MCS label creations in directory.

[Stephen Smalley]

On Wed, 2011-10-19 at 11:31 -0400, Joshua Brindle wrote:
> Christopher J. PeBenito wrote:
> > On 10/14/11 11:57, Daniel J Walsh wrote:
> >> Eric and I have come up with the following syntax for this behaviour.
> >>
> >> default_trans level dir_file_class_set parent;
> >
> > I think we want this to be "range" instead of "level", since the field is actually a range.
> >
> >> default_trans user dir_file_class_set process;
> >> default_trans role file parent;
> >
> > Isn't there a better set of tokens than this?  Why not make it default_user, default_role, default_type, and default_range?  Creating an object doesn't really imply a transition, so "trans" seems misleading.
> >
> 
> I agree with Chris. This will actually let you make things not transition by 
> default so _trans is misleading. Further, "process" shouldn't be a token since 
> it is an object class (you couldn't actually parse policy with Eric's patches 
> could you?). I don't like "parent" as a token either, and SELinux doesn't know 
> anything about processes and parents anyway. SDS's suggestions a while back are 
> more appropriate IMO, since SELinux does know what source and target are.

Unsurprisingly I agree with my original suggestions.  Also, I don't see
that you've addressed the issue of range/level defaults needing to
specify whether you want to inherit the low level, the high level or the
complete range of the source or the target contexts.

-- 
Stephen Smalley
National Security Agency


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

Re: I would like to change the behavior of MCS label creations in directory.

[Eric Paris]

On Wed, Oct 19, 2011 at 12:26 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Wed, 2011-10-19 at 11:31 -0400, Joshua Brindle wrote:
>> Christopher J. PeBenito wrote:
>> > On 10/14/11 11:57, Daniel J Walsh wrote:
>> >> Eric and I have come up with the following syntax for this behaviour.
>> >>
>> >> default_trans level dir_file_class_set parent;
>> >
>> > I think we want this to be "range" instead of "level", since the field is actually a range.
>> >
>> >> default_trans user dir_file_class_set process;
>> >> default_trans role file parent;
>> >
>> > Isn't there a better set of tokens than this?  Why not make it default_user, default_role, default_type, and default_range?  Creating an object doesn't really imply a transition, so "trans" seems misleading.
>> >
>>
>> I agree with Chris. This will actually let you make things not transition by
>> default so _trans is misleading. Further, "process" shouldn't be a token since
>> it is an object class (you couldn't actually parse policy with Eric's patches
>> could you?). I don't like "parent" as a token either, and SELinux doesn't know
>> anything about processes and parents anyway. SDS's suggestions a while back are
>> more appropriate IMO, since SELinux does know what source and target are.
>
> Unsurprisingly I agree with my original suggestions.  Also, I don't see
> that you've addressed the issue of range/level defaults needing to
> specify whether you want to inherit the low level, the high level or the
> complete range of the source or the target contexts.

A month later and I'm finally back looking at this.  I'm not certain
looking through the thread what your original suggestions were!  I
don't see an example of the syntax you want to see.  My best guess is
people would like to see:

default_user [class_set] {source, target};
default_role [class_set] {source, target};
default_type [class_set] {source, target};
default_range [class_set] {source, target, lub};

Is this right?


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

Re: I would like to change the behavior of MCS label creations in directory.

[Stephen Smalley]

On Tue, 2011-11-22 at 13:59 -0500, Eric Paris wrote:
> On Wed, Oct 19, 2011 at 12:26 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > On Wed, 2011-10-19 at 11:31 -0400, Joshua Brindle wrote:
> >> Christopher J. PeBenito wrote:
> >> > On 10/14/11 11:57, Daniel J Walsh wrote:
> >> >> Eric and I have come up with the following syntax for this behaviour.
> >> >>
> >> >> default_trans level dir_file_class_set parent;
> >> >
> >> > I think we want this to be "range" instead of "level", since the field is actually a range.
> >> >
> >> >> default_trans user dir_file_class_set process;
> >> >> default_trans role file parent;
> >> >
> >> > Isn't there a better set of tokens than this?  Why not make it default_user, default_role, default_type, and default_range?  Creating an object doesn't really imply a transition, so "trans" seems misleading.
> >> >
> >>
> >> I agree with Chris. This will actually let you make things not transition by
> >> default so _trans is misleading. Further, "process" shouldn't be a token since
> >> it is an object class (you couldn't actually parse policy with Eric's patches
> >> could you?). I don't like "parent" as a token either, and SELinux doesn't know
> >> anything about processes and parents anyway. SDS's suggestions a while back are
> >> more appropriate IMO, since SELinux does know what source and target are.
> >
> > Unsurprisingly I agree with my original suggestions.  Also, I don't see
> > that you've addressed the issue of range/level defaults needing to
> > specify whether you want to inherit the low level, the high level or the
> > complete range of the source or the target contexts.
> 
> A month later and I'm finally back looking at this.  I'm not certain
> looking through the thread what your original suggestions were!  I
> don't see an example of the syntax you want to see.  My best guess is
> people would like to see:
> 
> default_user [class_set] {source, target};
> default_role [class_set] {source, target};
> default_type [class_set] {source, target};
> default_range [class_set] {source, target, lub};
> 
> Is this right?

I only gave example syntax for the user/role/type cases (in the earlier
discussion I cited in the archives).  For the MLS range, you need to
distinguish low vs. high vs. full-range for source or target.  If you
want to be able to replace the current hardcoded logic in
mls_compute_sid with configurations, you'd need to be able to express
something like:

# For processes or sockets, inherit the complete source range.
default_range { process socket_class_set } source low-high;

# For files, inherit only the low/current level of the source range.
default_range dir_file_class_set source low;

-- 
Stephen Smalley
National Security Agency


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

Re: I would like to change the behavior of MCS label creations in directory.

[Eric Paris]

On Tue, Nov 22, 2011 at 2:25 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Tue, 2011-11-22 at 13:59 -0500, Eric Paris wrote:
>> On Wed, Oct 19, 2011 at 12:26 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> > On Wed, 2011-10-19 at 11:31 -0400, Joshua Brindle wrote:
>> >> Christopher J. PeBenito wrote:
>> >> > On 10/14/11 11:57, Daniel J Walsh wrote:
>> >> >> Eric and I have come up with the following syntax for this behaviour.
>> >> >>
>> >> >> default_trans level dir_file_class_set parent;
>> >> >
>> >> > I think we want this to be "range" instead of "level", since the field is actually a range.
>> >> >
>> >> >> default_trans user dir_file_class_set process;
>> >> >> default_trans role file parent;
>> >> >
>> >> > Isn't there a better set of tokens than this?  Why not make it default_user, default_role, default_type, and default_range?  Creating an object doesn't really imply a transition, so "trans" seems misleading.
>> >> >
>> >>
>> >> I agree with Chris. This will actually let you make things not transition by
>> >> default so _trans is misleading. Further, "process" shouldn't be a token since
>> >> it is an object class (you couldn't actually parse policy with Eric's patches
>> >> could you?). I don't like "parent" as a token either, and SELinux doesn't know
>> >> anything about processes and parents anyway. SDS's suggestions a while back are
>> >> more appropriate IMO, since SELinux does know what source and target are.
>> >
>> > Unsurprisingly I agree with my original suggestions.  Also, I don't see
>> > that you've addressed the issue of range/level defaults needing to
>> > specify whether you want to inherit the low level, the high level or the
>> > complete range of the source or the target contexts.
>>
>> A month later and I'm finally back looking at this.  I'm not certain
>> looking through the thread what your original suggestions were!  I
>> don't see an example of the syntax you want to see.  My best guess is
>> people would like to see:
>>
>> default_user [class_set] {source, target};
>> default_role [class_set] {source, target};
>> default_type [class_set] {source, target};
>> default_range [class_set] {source, target, lub};
>>
>> Is this right?
>
> I only gave example syntax for the user/role/type cases (in the earlier
> discussion I cited in the archives).  For the MLS range, you need to
> distinguish low vs. high vs. full-range for source or target.  If you
> want to be able to replace the current hardcoded logic in
> mls_compute_sid with configurations, you'd need to be able to express
> something like:
>
> # For processes or sockets, inherit the complete source range.
> default_range { process socket_class_set } source low-high;
>
> # For files, inherit only the low/current level of the source range.
> default_range dir_file_class_set source low;

Are you suggesting we don't offer a lub option?


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

Re: I would like to change the behavior of MCS label creations in directory.

[Stephen Smalley]

On Tue, 2011-11-22 at 14:37 -0500, Eric Paris wrote:
> On Tue, Nov 22, 2011 at 2:25 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > On Tue, 2011-11-22 at 13:59 -0500, Eric Paris wrote:
> >> On Wed, Oct 19, 2011 at 12:26 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> >> > On Wed, 2011-10-19 at 11:31 -0400, Joshua Brindle wrote:
> >> >> Christopher J. PeBenito wrote:
> >> >> > On 10/14/11 11:57, Daniel J Walsh wrote:
> >> >> >> Eric and I have come up with the following syntax for this behaviour.
> >> >> >>
> >> >> >> default_trans level dir_file_class_set parent;
> >> >> >
> >> >> > I think we want this to be "range" instead of "level", since the field is actually a range.
> >> >> >
> >> >> >> default_trans user dir_file_class_set process;
> >> >> >> default_trans role file parent;
> >> >> >
> >> >> > Isn't there a better set of tokens than this?  Why not make it default_user, default_role, default_type, and default_range?  Creating an object doesn't really imply a transition, so "trans" seems misleading.
> >> >> >
> >> >>
> >> >> I agree with Chris. This will actually let you make things not transition by
> >> >> default so _trans is misleading. Further, "process" shouldn't be a token since
> >> >> it is an object class (you couldn't actually parse policy with Eric's patches
> >> >> could you?). I don't like "parent" as a token either, and SELinux doesn't know
> >> >> anything about processes and parents anyway. SDS's suggestions a while back are
> >> >> more appropriate IMO, since SELinux does know what source and target are.
> >> >
> >> > Unsurprisingly I agree with my original suggestions.  Also, I don't see
> >> > that you've addressed the issue of range/level defaults needing to
> >> > specify whether you want to inherit the low level, the high level or the
> >> > complete range of the source or the target contexts.
> >>
> >> A month later and I'm finally back looking at this.  I'm not certain
> >> looking through the thread what your original suggestions were!  I
> >> don't see an example of the syntax you want to see.  My best guess is
> >> people would like to see:
> >>
> >> default_user [class_set] {source, target};
> >> default_role [class_set] {source, target};
> >> default_type [class_set] {source, target};
> >> default_range [class_set] {source, target, lub};
> >>
> >> Is this right?
> >
> > I only gave example syntax for the user/role/type cases (in the earlier
> > discussion I cited in the archives).  For the MLS range, you need to
> > distinguish low vs. high vs. full-range for source or target.  If you
> > want to be able to replace the current hardcoded logic in
> > mls_compute_sid with configurations, you'd need to be able to express
> > something like:
> >
> > # For processes or sockets, inherit the complete source range.
> > default_range { process socket_class_set } source low-high;
> >
> > # For files, inherit only the low/current level of the source range.
> > default_range dir_file_class_set source low;
> 
> Are you suggesting we don't offer a lub option?

I don't think we strictly need it in a first implementation.  We do need
the ability to distinguish inherit-full-range from inherit-low-level
though.

-- 
Stephen Smalley
National Security Agency


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

Re: I would like to change the behavior of MCS label creations in directory.

[Eric Paris]

On Tue, Nov 22, 2011 at 2:39 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Tue, 2011-11-22 at 14:37 -0500, Eric Paris wrote:
>> On Tue, Nov 22, 2011 at 2:25 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> > On Tue, 2011-11-22 at 13:59 -0500, Eric Paris wrote:

>> >> A month later and I'm finally back looking at this.  I'm not certain
>> >> looking through the thread what your original suggestions were!  I
>> >> don't see an example of the syntax you want to see.  My best guess is
>> >> people would like to see:
>> >>
>> >> default_user [class_set] {source, target};
>> >> default_role [class_set] {source, target};
>> >> default_type [class_set] {source, target};
>> >> default_range [class_set] {source, target, lub};
>> >>
>> >> Is this right?
>> >
>> > I only gave example syntax for the user/role/type cases (in the earlier
>> > discussion I cited in the archives).  For the MLS range, you need to
>> > distinguish low vs. high vs. full-range for source or target.  If you
>> > want to be able to replace the current hardcoded logic in
>> > mls_compute_sid with configurations, you'd need to be able to express
>> > something like:
>> >
>> > # For processes or sockets, inherit the complete source range.
>> > default_range { process socket_class_set } source low-high;
>> >
>> > # For files, inherit only the low/current level of the source range.
>> > default_range dir_file_class_set source low;
>>
>> Are you suggesting we don't offer a lub option?
>
> I don't think we strictly need it in a first implementation.  We do need
> the ability to distinguish inherit-full-range from inherit-low-level
> though.

I'm just trying to make sure the policy language is ok with it
assuming someone wants it.  But i'm happy not doing it right now.

default_range { process socket_class_set } both lub;

Seems like it could work without too much trouble to the language.
Ok, I've got it!

-Eric


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

Re: I would like to change the behavior of MCS label creations in directory.

[Kyle Moffett]

On Wed, Oct 19, 2011 at 11:31, Joshua Brindle <method@manicmethod.com> wrote:
> Christopher J. PeBenito wrote:
>> On 10/14/11 11:57, Daniel J Walsh wrote:
>>> Eric and I have come up with the following syntax for this behaviour.
>>>
>>> default_trans level dir_file_class_set parent;
>>
>> I think we want this to be "range" instead of "level", since the field is
>> actually a range.
>>
>>> default_trans user dir_file_class_set process;
>>> default_trans role file parent;
>>
>> Isn't there a better set of tokens than this?  Why not make it
>> default_user, default_role, default_type, and default_range?  Creating an
>> object doesn't really imply a transition, so "trans" seems misleading.
>
> I agree with Chris. This will actually let you make things not transition by
> default so _trans is misleading. Further, "process" shouldn't be a token
> since it is an object class (you couldn't actually parse policy with Eric's
> patches could you?). I don't like "parent" as a token either, and SELinux
> doesn't know anything about processes and parents anyway. SDS's suggestions
> a while back are more appropriate IMO, since SELinux does know what source
> and target are.

Why not extend the behavior of type_transition/range_transition/etc to
allow the existing "self" keyword (maybe with "subject" as a synonym)
and add a new "object" keyword?

IE, allow something like this:
  range_transition myapp_t myapp_data_t:file self;
  range_transition myapp_t myapp_log_t:file object;

Cheers,
Kyle Moffett

-- 
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/


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

Re: I would like to change the behavior of MCS label creations in directory.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/19/2011 11:31 AM, Joshua Brindle wrote:
> Christopher J. PeBenito wrote:
>> On 10/14/11 11:57, Daniel J Walsh wrote:
>>> Eric and I have come up with the following syntax for this
>>> behaviour.
>>> 
>>> default_trans level dir_file_class_set parent;
>> 
>> I think we want this to be "range" instead of "level", since the
>> field is actually a range.
>> 
>>> default_trans user dir_file_class_set process; default_trans
>>> role file parent;
>> 
>> Isn't there a better set of tokens than this?  Why not make it 
>> default_user, default_role, default_type, and default_range?
>> Creating an object doesn't really imply a transition, so "trans"
>> seems misleading.
>> 
> 
> I agree with Chris. This will actually let you make things not 
> transition by default so _trans is misleading. Further, "process" 
> shouldn't be a token since it is an object class (you couldn't
> actually parse policy with Eric's patches could you?). I don't like
> "parent" as a token either, and SELinux doesn't know anything about
> processes and parents anyway. SDS's suggestions a while back are
> more appropriate IMO, since SELinux does know what source and
> target are.
> 
> -- 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.
> 
> 

We can parse and you are allowed to use process in both places.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6fC74ACgkQrlYvE4MpobPZdgCgnc/98H1ZvyOlDvqgQZdJjLkn
KlsAn2RIHOa/tN9qH9mPfbdHoQacetC+
=YPYh
-----END PGP SIGNATURE-----

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

Re: I would like to change the behavior of MCS label creations in directory.

[Joshua Brindle]

Daniel J Walsh wrote:
> We can parse and you are allowed to use process in both places.

Even still, SELinux does not internally (either in the security server or the 
compiler) know what a process is and some users of the compiler have a different 
concept of subject than Linux does (e.g., Xen)

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

Re: I would like to change the behavior of MCS label creations in directory.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/19/2011 01:47 PM, Joshua Brindle wrote:
> Daniel J Walsh wrote:
>> We can parse and you are allowed to use process in both places.
> 
> Even still, SELinux does not internally (either in the security
> server or the compiler) know what a process is and some users of
> the compiler have a different concept of subject than Linux does
> (e.g., Xen)
The latest syntax is what Eric wrote and he is away on Vacation right
now, so I think we should wait until he comes back to get his point of
view.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6fDckACgkQrlYvE4MpobOBcgCgzGH1Xhq3kKq7q+1so7oXDYBi
LCIAoNY3HnfEZBWd2GFHRpAjkrIxF6M8
=yxOQ
-----END PGP SIGNATURE-----

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

Re: I would like to change the behavior of MCS label creations in directory.

[Guido Trentalancia]

On Thu, 2011-09-22 at 15:53 -0400, Daniel J Walsh wrote:
> Currently if I create a directory labeled
> 
> etc_t:s0:c1
> 
> And with a process running as unconfined_t:s0-s0:c0.c1023 create a
> file within the directory, the file gets created with the label
> etc_t:s0.   I would like to change the behavior to creating the file
> as etc_t:s0:c1.

It almost seems a bug to me (MCS category of parent directory is not
inherited upon new file creation)... especially if a user which has not
access to that specific category was currently able to read/write that
(uncategorized) file in a categorized directory.

> That way an administrator could modify files within a sandbox and have
> the files be labeled correctly.
> 
> I believe this behavior differs from MLS but believe this would be
> what the admin expects.
> 
> Is changing this a kernel or policy issue?

What the reference policy perhaps should NOT allow is the creation of a
file in the first place. I mean eventually the policy should not allow
the creation of an uncategorized file in a categorized directory.
Although it's a somewhat different issue, which can eventually be
defined later. We would first need to tackle the kernel (how things are
done), then we can eventually adjust the reference policy (define what
can and what cannot be done).

Regards,

Guido


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