[RFC] clarifications for -l to newrole.1

[RFC] clarifications for -l to newrole.1

[Michael C Thompson]

Based on some discussion from irc and some complaints I have received, 
I'm proposing this addition (comments or other suggestions welcome) to 
the newrole manage. This example section would slot in right after the 
DESCRIPTION section. Patch below.

EXAMPLE
        Changing sensitivity only:
           # id -Z
           user:role:type:SystemLow-SystemHigh
           # newrole -l Unclassified
           # id -Z
           user:role:type:Unclassified-SystemHigh

        Changing sensitivity and clearance:
           # id -Z
           user:role:type:SystemLow-SystemHigh
           # newrole -l Unclassified-Unclassified
           # id -Z
           user:role:type:Unclassified-Unclassified

Thanks,
Mike

---

--- newrole.1.orig      2007-01-11 14:24:51.000000000 -0600
+++ newrole.1   2007-01-11 14:31:51.000000000 -0600
@@ -57,6 +57,21 @@
  .B --version
  shows the current version of newrole
  .PP
+.SH EXAMPLE
+.br
+Changing sensitivity only:
+   # id -Z
+   user:role:type:SystemLow-SystemHigh
+   # newrole -l Unclassified
+   # id -Z
+   user:role:type:Unclassified-SystemHigh
+.PP
+Changing sensitivity and clearance:
+   # id -Z
+   user:role:type:SystemLow-SystemHigh
+   # newrole -l Unclassified-Unclassified
+   # id -Z
+   user:role:type:Unclassified-Unclassified
  .SH FILES
  /etc/passwd - user account information
  .br



--
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: [RFC] clarifications for -l to newrole.1

[Stephen Smalley]

On Thu, 2007-01-11 at 14:39 -0600, Michael C Thompson wrote:
> Based on some discussion from irc and some complaints I have received, 
> I'm proposing this addition (comments or other suggestions welcome) to 
> the newrole manage. This example section would slot in right after the 
> DESCRIPTION section. Patch below.
> 
> EXAMPLE
>         Changing sensitivity only:
>            # id -Z
>            user:role:type:SystemLow-SystemHigh
>            # newrole -l Unclassified
>            # id -Z
>            user:role:type:Unclassified-SystemHigh

How does SystemLow differ from Unclassified here (in meaning, not just
value)?  If SystemLow is supposed to be a special label for system
objects, then why have users login at that level at all?

>         Changing sensitivity and clearance:
>            # id -Z
>            user:role:type:SystemLow-SystemHigh
>            # newrole -l Unclassified-Unclassified
>            # id -Z
>            user:role:type:Unclassified-Unclassified

When would you envision a user doing the above?  Trying to ensure that
any process he subsequently starts cannot escalate to higher levels?

If you are going to provide an example, use real output (i.e. not just
user:role:type).  Please include an example of changing roles too since
that is more common.  Also, fix the SEE ALSO list please (runas ->
runcon, and drop su as it is no longer relevant).

AUTHORS list is also badly out of date there.  Let's see...you, Dan
Walsh, Steve Grubb, and Darrel Goeddel should likely be added, and while
the earlier authors should be retained, their email addresses are
obsolete and should be dropped.

-- 
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: [RFC] clarifications for -l to newrole.1

[Stephen Smalley]

On Thu, 2007-01-11 at 16:02 -0500, Stephen Smalley wrote:
> On Thu, 2007-01-11 at 14:39 -0600, Michael C Thompson wrote:
> > Based on some discussion from irc and some complaints I have received, 
> > I'm proposing this addition (comments or other suggestions welcome) to 
> > the newrole manage. This example section would slot in right after the 
> > DESCRIPTION section. Patch below.
> > 
> > EXAMPLE
> >         Changing sensitivity only:
> >            # id -Z
> >            user:role:type:SystemLow-SystemHigh
> >            # newrole -l Unclassified
> >            # id -Z
> >            user:role:type:Unclassified-SystemHigh
> 
> How does SystemLow differ from Unclassified here (in meaning, not just
> value)?  If SystemLow is supposed to be a special label for system
> objects, then why have users login at that level at all?
> 
> >         Changing sensitivity and clearance:
> >            # id -Z
> >            user:role:type:SystemLow-SystemHigh
> >            # newrole -l Unclassified-Unclassified
> >            # id -Z
> >            user:role:type:Unclassified-Unclassified
> 
> When would you envision a user doing the above?  Trying to ensure that
> any process he subsequently starts cannot escalate to higher levels?
> 
> If you are going to provide an example, use real output (i.e. not just
> user:role:type).  Please include an example of changing roles too since
> that is more common.  Also, fix the SEE ALSO list please (runas ->
> runcon, and drop su as it is no longer relevant).

More examples for semanage would also be helpful, e.g.
	semanage login -m -r SystemLow-SystemHigh sds

-- 
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: [RFC] clarifications for -l to newrole.1

[Russell Coker]

On Friday 12 January 2007 08:02, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > EXAMPLE
> >         Changing sensitivity only:
> >            # id -Z
> >            user:role:type:SystemLow-SystemHigh
> >            # newrole -l Unclassified
> >            # id -Z
> >            user:role:type:Unclassified-SystemHigh
>
> How does SystemLow differ from Unclassified here (in meaning, not just
> value)?  If SystemLow is supposed to be a special label for system
> objects, then why have users login at that level at all?

In the context of the man page I don't think it matters.  The purpose is to 
clarify an interface that confuses many people.

> >         Changing sensitivity and clearance:
> >            # id -Z
> >            user:role:type:SystemLow-SystemHigh
> >            # newrole -l Unclassified-Unclassified
> >            # id -Z
> >            user:role:type:Unclassified-Unclassified
>
> When would you envision a user doing the above?  Trying to ensure that
> any process he subsequently starts cannot escalate to higher levels?

MCS as currently released in Red Hat and Debian only uses the high level.  MCS 
will always use the high level as the main access control mechanism.  
Therefore this behaviour gets in the way for MCS.

Maybe we should have newrole determine whether MCS or MLS is being used and 
alter it's behaviour accordingly?

> If you are going to provide an example, use real output (i.e. not just
> user:role:type).  Please include an example of changing roles too since
> that is more common.  Also, fix the SEE ALSO list please (runas ->
> runcon, and drop su as it is no longer relevant).

Do people often get confused about changing roles?  It seems to me that 
changing roles is obvious to people (EG the numerous people who have logged 
in to my SE Linux play machines and run "newrole -r sysadm_r" within minutes 
of first learning about it).  Changing levels is not obvious (in it's current 
implementation) which is why there was a long IRC discussion about it where 
even experience SE Linux users had some confusion.

-- 
russell@coker.com.au
http://etbe.blogspot.com/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
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: [RFC] clarifications for -l to newrole.1

[Michael C Thompson]

Stephen Smalley wrote:
> On Thu, 2007-01-11 at 14:39 -0600, Michael C Thompson wrote:
>> Based on some discussion from irc and some complaints I have received,
>> I'm proposing this addition (comments or other suggestions welcome) to
>> the newrole manage. This example section would slot in right after the
>> DESCRIPTION section. Patch below.
>>
>> EXAMPLE
>>         Changing sensitivity only:
>>            # id -Z
>>            user:role:type:SystemLow-SystemHigh
>>            # newrole -l Unclassified
>>            # id -Z
>>            user:role:type:Unclassified-SystemHigh
> 
> How does SystemLow differ from Unclassified here (in meaning, not just
> value)?  If SystemLow is supposed to be a special label for system
> objects, then why have users login at that level at all?

There wasn't any specific meaning with that, if it would be preferable, 
it can go from Unclassified to Secret, or whatever people would like to see.

>>         Changing sensitivity and clearance:
>>            # id -Z
>>            user:role:type:SystemLow-SystemHigh
>>            # newrole -l Unclassified-Unclassified
>>            # id -Z
>>            user:role:type:Unclassified-Unclassified
> 
> When would you envision a user doing the above?  Trying to ensure that
> any process he subsequently starts cannot escalate to higher levels?

That seems reasonable, since, tbh, I hadn't really thought of a 
use-case. I just know that should the desire be there to change the 
clearance, this would show how to do it.... it is also inaccurate, since 
"user:role:type:Unclassified-Unclassified" would be condensed down to 
"user:role:type:Unclassified".

> If you are going to provide an example, use real output (i.e. not just
> user:role:type).  Please include an example of changing roles too since
> that is more common.  Also, fix the SEE ALSO list please (runas ->
> runcon, and drop su as it is no longer relevant).

Will do. I'll take an example from the current LSPP work.

> AUTHORS list is also badly out of date there.  Let's see...you, Dan
> Walsh, Steve Grubb, and Darrel Goeddel should likely be added, and while
> the earlier authors should be retained, their email addresses are
> obsolete and should be dropped.

OK, will include that in the patch.

Thanks,
Mike


--
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: [RFC] clarifications for -l to newrole.1

[Michael C Thompson]

Stephen Smalley wrote:
> On Thu, 2007-01-11 at 14:39 -0600, Michael C Thompson wrote:
>> Based on some discussion from irc and some complaints I have received,
>> I'm proposing this addition (comments or other suggestions welcome) to
>> the newrole manage. This example section would slot in right after the
>> DESCRIPTION section. Patch below.
>>
>> EXAMPLE
>>         Changing sensitivity only:
>>            # id -Z
>>            user:role:type:SystemLow-SystemHigh
>>            # newrole -l Unclassified
>>            # id -Z
>>            user:role:type:Unclassified-SystemHigh
> 
> How does SystemLow differ from Unclassified here (in meaning, not just
> value)?  If SystemLow is supposed to be a special label for system
> objects, then why have users login at that level at all?
> 
>>         Changing sensitivity and clearance:
>>            # id -Z
>>            user:role:type:SystemLow-SystemHigh
>>            # newrole -l Unclassified-Unclassified
>>            # id -Z
>>            user:role:type:Unclassified-Unclassified
> 
> When would you envision a user doing the above?  Trying to ensure that
> any process he subsequently starts cannot escalate to higher levels?
> 
> If you are going to provide an example, use real output (i.e. not just
> user:role:type).  Please include an example of changing roles too since
> that is more common.  Also, fix the SEE ALSO list please (runas ->
> runcon, and drop su as it is no longer relevant).
> 
> AUTHORS list is also badly out of date there.  Let's see...you, Dan
> Walsh, Steve Grubb, and Darrel Goeddel should likely be added, and while
> the earlier authors should be retained, their email addresses are
> obsolete and should be dropped.

Based on the above comments, this is the patch, rehashed.

Thanks,
Mike

---

--- newrole.1.orig      2007-01-11 14:24:51.000000000 -0600
+++ newrole.1   2007-01-11 17:57:06.000000000 -0600
@@ -57,16 +57,45 @@
  .B --version
  shows the current version of newrole
  .PP
+.SH EXAMPLE
+.br
+Changing role:
+   # id -Z
+   staff_u:staff_r:staff_t:SystemLow-SystemHigh
+   # newrole -r sysadm_r
+   # id -Z
+   staff_u:sysadm_r:sysadm_t:SystemLow-SystemHigh
+
+Changing sensitivity only:
+   # id -Z
+   staff_u:sysadm_r:sysadm_t:Unclassified-SystemHigh
+   # newrole -l Secret
+   # id -Z
+   staff_u:sysadm_r:sysadm_t:Secret-SystemHigh
+
+.PP
+Changing sensitivity and clearance:
+   # id -Z
+   staff_u:sysadm_r:sysadm_t:Unclassified-SystemHigh
+   # newrole -l Secret-Secret
+   # id -Z
+   staff_u:sysadm_r:sysadm_t:Secret
+
  .SH FILES
  /etc/passwd - user account information
  .br
  /etc/shadow - encrypted passwords and age information
+.br
+/etc/selinux/<policy>/contexts/default_type - default types for roles
+.br
  .SH SEE ALSO
-.B su
-(1),
-.B runas
+.B runcon
  (1)
  .SH AUTHORS
  .nf
-Tim Fraser (tfraser@tislabs.com)
-Anthony Colatrella (amcolat@epoch.ncsc.mil)
+Dan Walsh <dwalsh@redhat.com>
+Steve Grubb <sgrubb@redhat.com>
+Darrel Goeddel <DGoeddel@trustedcs.com>
+Michael Thompson <mcthomps@us.ibm.com>
+Tim Fraser
+Anthony Colatrella


--
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: [RFC] clarifications for -l to newrole.1

[Stephen Smalley]

On Fri, 2007-01-12 at 09:07 +1100, Russell Coker wrote:
> On Friday 12 January 2007 08:02, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > > EXAMPLE
> > >         Changing sensitivity only:
> > >            # id -Z
> > >            user:role:type:SystemLow-SystemHigh
> > >            # newrole -l Unclassified
> > >            # id -Z
> > >            user:role:type:Unclassified-SystemHigh
> >
> > How does SystemLow differ from Unclassified here (in meaning, not just
> > value)?  If SystemLow is supposed to be a special label for system
> > objects, then why have users login at that level at all?
> 
> In the context of the man page I don't think it matters.  The purpose is to 
> clarify an interface that confuses many people.

I'm concerned about two things:
- the example being meaningful to the user (what does SystemLow mean
relative to Unclassified in the user's mind),
- the actual policy being correct (is it correct for users to login at
SystemLow and then switch to Unclassified manually, or should they be
logging in at Unclassified directly and not even allowed to directly
login at SystemLow).

> > >         Changing sensitivity and clearance:
> > >            # id -Z
> > >            user:role:type:SystemLow-SystemHigh
> > >            # newrole -l Unclassified-Unclassified
> > >            # id -Z
> > >            user:role:type:Unclassified-Unclassified
> >
> > When would you envision a user doing the above?  Trying to ensure that
> > any process he subsequently starts cannot escalate to higher levels?
> 
> MCS as currently released in Red Hat and Debian only uses the high level.  MCS 
> will always use the high level as the main access control mechanism.  
> Therefore this behaviour gets in the way for MCS.
> 
> Maybe we should have newrole determine whether MCS or MLS is being used and 
> alter it's behaviour accordingly?

Under MCS, IIUC, one never switches the level on a process; your
sensitivity (low) is always set to SystemLow and your clearance (high)
is just set to your authorized category set at login, and you manually
use chcat or similar commands to label files with categories.  So you
wouldn't use newrole -l at all under MCS.

In any event, newrole shouldn't be aware of MCS vs. MLS at all; that's
policy logic.

> > If you are going to provide an example, use real output (i.e. not just
> > user:role:type).  Please include an example of changing roles too since
> > that is more common.  Also, fix the SEE ALSO list please (runas ->
> > runcon, and drop su as it is no longer relevant).
> 
> Do people often get confused about changing roles?  It seems to me that 
> changing roles is obvious to people (EG the numerous people who have logged 
> in to my SE Linux play machines and run "newrole -r sysadm_r" within minutes 
> of first learning about it).  Changing levels is not obvious (in it's current 
> implementation) which is why there was a long IRC discussion about it where 
> even experience SE Linux users had some confusion.

It may be obvious, but if we are going to provide examples in the man
page, we should include the common case too.

-- 
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: [RFC] clarifications for -l to newrole.1

[Stephen Smalley]

On Thu, 2007-01-11 at 18:04 -0600, Michael C Thompson wrote:
> Stephen Smalley wrote:
> > On Thu, 2007-01-11 at 14:39 -0600, Michael C Thompson wrote:
> >> Based on some discussion from irc and some complaints I have received,
> >> I'm proposing this addition (comments or other suggestions welcome) to
> >> the newrole manage. This example section would slot in right after the
> >> DESCRIPTION section. Patch below.
> >>
> >> EXAMPLE
> >>         Changing sensitivity only:
> >>            # id -Z
> >>            user:role:type:SystemLow-SystemHigh
> >>            # newrole -l Unclassified
> >>            # id -Z
> >>            user:role:type:Unclassified-SystemHigh
> > 
> > How does SystemLow differ from Unclassified here (in meaning, not just
> > value)?  If SystemLow is supposed to be a special label for system
> > objects, then why have users login at that level at all?
> > 
> >>         Changing sensitivity and clearance:
> >>            # id -Z
> >>            user:role:type:SystemLow-SystemHigh
> >>            # newrole -l Unclassified-Unclassified
> >>            # id -Z
> >>            user:role:type:Unclassified-Unclassified
> > 
> > When would you envision a user doing the above?  Trying to ensure that
> > any process he subsequently starts cannot escalate to higher levels?
> > 
> > If you are going to provide an example, use real output (i.e. not just
> > user:role:type).  Please include an example of changing roles too since
> > that is more common.  Also, fix the SEE ALSO list please (runas ->
> > runcon, and drop su as it is no longer relevant).
> > 
> > AUTHORS list is also badly out of date there.  Let's see...you, Dan
> > Walsh, Steve Grubb, and Darrel Goeddel should likely be added, and while
> > the earlier authors should be retained, their email addresses are
> > obsolete and should be dropped.
> 
> Based on the above comments, this is the patch, rehashed.
> 
> Thanks,
> Mike
> 
> ---
> 
> --- newrole.1.orig      2007-01-11 14:24:51.000000000 -0600
> +++ newrole.1   2007-01-11 17:57:06.000000000 -0600
> @@ -57,16 +57,45 @@
>   .B --version
>   shows the current version of newrole
>   .PP
> +.SH EXAMPLE
> +.br
> +Changing role:
> +   # id -Z
> +   staff_u:staff_r:staff_t:SystemLow-SystemHigh
> +   # newrole -r sysadm_r
> +   # id -Z
> +   staff_u:sysadm_r:sysadm_t:SystemLow-SystemHigh
> +
> +Changing sensitivity only:
> +   # id -Z
> +   staff_u:sysadm_r:sysadm_t:Unclassified-SystemHigh
> +   # newrole -l Secret
> +   # id -Z
> +   staff_u:sysadm_r:sysadm_t:Secret-SystemHigh
> +
> +.PP
> +Changing sensitivity and clearance:
> +   # id -Z
> +   staff_u:sysadm_r:sysadm_t:Unclassified-SystemHigh
> +   # newrole -l Secret-Secret
> +   # id -Z
> +   staff_u:sysadm_r:sysadm_t:Secret
> +
>   .SH FILES
>   /etc/passwd - user account information
>   .br
>   /etc/shadow - encrypted passwords and age information
> +.br
> +/etc/selinux/<policy>/contexts/default_type - default types for roles
> +.br
>   .SH SEE ALSO
> -.B su
> -(1),
> -.B runas
> +.B runcon
>   (1)
>   .SH AUTHORS
>   .nf
> -Tim Fraser (tfraser@tislabs.com)
> -Anthony Colatrella (amcolat@epoch.ncsc.mil)
> +Dan Walsh <dwalsh@redhat.com>
> +Steve Grubb <sgrubb@redhat.com>
> +Darrel Goeddel <DGoeddel@trustedcs.com>
> +Michael Thompson <mcthomps@us.ibm.com>
> +Tim Fraser
> +Anthony Colatrella

Looks sane as far as content is concerned, although I don't understand
the author ordering (I'd typically expect alphabetically by last name or
by amount of involvement or by date of involvement).  But it doesn't
apply (whitespace damage) for me.   Also, please make the patch -p1
appliable from the top of the tree, e.g. result of svn diff
policycoreutils. 

-- 
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: [RFC] clarifications for -l to newrole.1

[Michael C Thompson]

Stephen Smalley wrote:
> On Fri, 2007-01-12 at 09:07 +1100, Russell Coker wrote:
>> On Friday 12 January 2007 08:02, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>>> EXAMPLE
>>>>         Changing sensitivity only:
>>>>            # id -Z
>>>>            user:role:type:SystemLow-SystemHigh
>>>>            # newrole -l Unclassified
>>>>            # id -Z
>>>>            user:role:type:Unclassified-SystemHigh
>>> How does SystemLow differ from Unclassified here (in meaning, not just
>>> value)?  If SystemLow is supposed to be a special label for system
>>> objects, then why have users login at that level at all?
>> In the context of the man page I don't think it matters.  The purpose is to
>> clarify an interface that confuses many people.
> 
> I'm concerned about two things:
> - the example being meaningful to the user (what does SystemLow mean
> relative to Unclassified in the user's mind),
> - the actual policy being correct (is it correct for users to login at
> SystemLow and then switch to Unclassified manually, or should they be
> logging in at Unclassified directly and not even allowed to directly
> login at SystemLow).

Currently, in the MLS policy, the default behaviour is to have users 
login at SystemLow. If this is not what you would expect, then we should 
probably change the default levels assumed for users on login.


Mike


--
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: [RFC] clarifications for -l to newrole.1

[Michael C Thompson]

Stephen Smalley wrote:
<snip>
> Looks sane as far as content is concerned, although I don't understand
> the author ordering (I'd typically expect alphabetically by last name or
> by amount of involvement or by date of involvement).  But it doesn't
> apply (whitespace damage) for me.   Also, please make the patch -p1
> appliable from the top of the tree, e.g. result of svn diff
> policycoreutils.

I've reordered the authors in alphabetical order, and re-patched with -p1.

Thanks,
Mike

---

--- policycoreutils-1.33.12.orig/newrole/newrole.1      2007-01-11 
13:01:39.000000000 -0600
+++ policycoreutils-1.33.12/newrole/newrole.1   2007-01-12 
10:15:14.000000000 -0600
@@ -57,16 +57,45 @@
  .B --version
  shows the current version of newrole
  .PP
+.SH EXAMPLE
+.br
+Changing role:
+   # id -Z
+   staff_u:staff_r:staff_t:SystemLow-SystemHigh
+   # newrole -r sysadm_r
+   # id -Z
+   staff_u:sysadm_r:sysadm_t:SystemLow-SystemHigh
+
+Changing sensitivity only:
+   # id -Z
+   staff_u:sysadm_r:sysadm_t:Unclassified-SystemHigh
+   # newrole -l Secret
+   # id -Z
+   staff_u:sysadm_r:sysadm_t:Secret-SystemHigh
+
+.PP
+Changing sensitivity and clearance:
+   # id -Z
+   staff_u:sysadm_r:sysadm_t:Unclassified-SystemHigh
+   # newrole -l Secret-Secret
+   # id -Z
+   staff_u:sysadm_r:sysadm_t:Secret
+
  .SH FILES
  /etc/passwd - user account information
  .br
  /etc/shadow - encrypted passwords and age information
+.br
+/etc/selinux/<policy>/contexts/default_type - default types for roles
+.br
  .SH SEE ALSO
-.B su
-(1),
-.B runas
+.B runcon
  (1)
  .SH AUTHORS
  .nf
-Tim Fraser (tfraser@tislabs.com)
-Anthony Colatrella (amcolat@epoch.ncsc.mil)
+Anthony Colatrella
+Tim Fraser
+Steve Grubb <sgrubb@redhat.com>
+Darrel Goeddel <DGoeddel@trustedcs.com>
+Michael Thompson <mcthomps@us.ibm.com>
+Dan Walsh <dwalsh@redhat.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: [RFC] clarifications for -l to newrole.1

[Casey Schaufler]

--- Michael C Thompson <thompsmc@us.ibm.com> wrote:

> Currently, in the MLS policy, the default behaviour
> is to have users 
> login at SystemLow. If this is not what you would
> expect, then we should 
> probably change the default levels assumed for users
> on login.

Allowing users to log in at SystemLow would not
be consistant with current best practice. I know
that neither Trusted Solaris nor Trusted Irix
allows that, and I don't think that HP/UX does
either. Even allowing for the additional
protections provided by TE letting users run with
the same MLS value as system files (unless you
have something lower than low!) is going to
set off warning bells in certain circles. Why
have MLS if you aren't going to use it to
protect your system data, after all? And yes,
I understand that there's lots more to SELinux
policy enforcement than MLS, and that the other
protections are more than sufficient to protect
the system files from users. Even with that,
users should be segregated from the system using
MLS since MLS is available. Belts, bracers,
garters, elastic and velcro make for a happy
and swift evaluation and an end user that
understands how the system is protected.


Casey Schaufler
casey@schaufler-ca.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: [RFC] clarifications for -l to newrole.1

[Stephen Smalley]

On Fri, 2007-01-12 at 10:11 -0600, Michael C Thompson wrote:
> Stephen Smalley wrote:
> > On Fri, 2007-01-12 at 09:07 +1100, Russell Coker wrote:
> >> On Friday 12 January 2007 08:02, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> >>>> EXAMPLE
> >>>>         Changing sensitivity only:
> >>>>            # id -Z
> >>>>            user:role:type:SystemLow-SystemHigh
> >>>>            # newrole -l Unclassified
> >>>>            # id -Z
> >>>>            user:role:type:Unclassified-SystemHigh
> >>> How does SystemLow differ from Unclassified here (in meaning, not just
> >>> value)?  If SystemLow is supposed to be a special label for system
> >>> objects, then why have users login at that level at all?
> >> In the context of the man page I don't think it matters.  The purpose is to
> >> clarify an interface that confuses many people.
> > 
> > I'm concerned about two things:
> > - the example being meaningful to the user (what does SystemLow mean
> > relative to Unclassified in the user's mind),
> > - the actual policy being correct (is it correct for users to login at
> > SystemLow and then switch to Unclassified manually, or should they be
> > logging in at Unclassified directly and not even allowed to directly
> > login at SystemLow).
> 
> Currently, in the MLS policy, the default behaviour is to have users 
> login at SystemLow. If this is not what you would expect, then we should 
> probably change the default levels assumed for users on login.

(cc'd Chad and Darrel to see what they think as well)

Conventionally I think SystemLow is inaccessible to ordinary users and
used to prevent modification of system objects.  Of course, with TE, one
can achieve such integrity protection more cleanly, but it may be
confusing to have a SystemLow level that is the default level for most
processes and files.  Simplest change would be to just drop the notion
of SystemLow from setrans.conf (i.e. s0 == Unclassified or whatever the
actual lowest level is).  More involved change would be to retain
SystemLow as a distinct level, only apply it to system objects, and move
up the default level for users and files to s1.

-- 
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: [RFC] clarifications for -l to newrole.1

[Joe Nall]

On Jan 12, 2007, at 11:22 AM, Casey Schaufler wrote:

>
> --- Michael C Thompson <thompsmc@us.ibm.com> wrote:
>
>> Currently, in the MLS policy, the default behaviour
>> is to have users
>> login at SystemLow. If this is not what you would
>> expect, then we should
>> probably change the default levels assumed for users
>> on login.
>
> Allowing users to log in at SystemLow would not
> be consistant with current best practice. I know
> that neither Trusted Solaris nor Trusted Irix
> allows that, and I don't think that HP/UX does
> either. Even allowing for the additional
> protections provided by TE letting users run with
> the same MLS value as system files (unless you
> have something lower than low!) is going to
> set off warning bells in certain circles. Why
> have MLS if you aren't going to use it to
> protect your system data, after all? And yes,
> I understand that there's lots more to SELinux
> policy enforcement than MLS, and that the other
> protections are more than sufficient to protect
> the system files from users. Even with that,
> users should be segregated from the system using
> MLS since MLS is available. Belts, bracers,
> garters, elastic and velcro make for a happy
> and swift evaluation and an end user that
> understands how the system is protected.

On HP-UX 10.26, normal users can login at syslo, which in our systems  
corresponds to unclassified. There is no special effort made to use  
MLS to protect the TCB (some files are syshi because of their  
contents). Does Trusted Irix use a distinct level or an implicit bit  
in the non SystemLow labels?

joe 

--
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: [RFC] clarifications for -l to newrole.1

[Casey Schaufler]

--- Joe Nall <joe@nall.com> wrote:


> On HP-UX 10.26, normal users can login at syslo,
> which in our systems  
> corresponds to unclassified.

Hmm.

> There is no special effort made to use  
> MLS to protect the TCB (some files are syshi because
> of their contents).

Hmm.

> Does Trusted Irix use a distinct level or
> an implicit bit in the non SystemLow labels?

Trix labels are "sophisticated". They include
both sensitivity (MSEN) and integrity (MINT)
components. A sensitivity can be MSEN_LOW
(SystemLow) MSEN_HIGH (SystemHigh), MSEN_ADMIN
(/etc/shadow), MSEN_TCSEC (with levels and
categories), or a couple other special types.
All TCB data is either MSEN_LOW or MSEN_ADMIN.
Users get MSEN_TCSEC labels, which can have
a level 0-255 and a set of categories.
MSEN_TCSEC labels dominate MSEN_LOW.

MINT is also used, with TCB data getting
MINT_HIGH labels and users getting MINT_BIBA.

In retrospect Trix labels are more complicated
than they need to be. I'm looking into a better
way for my "next" system.


Casey Schaufler
casey@schaufler-ca.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: [RFC] clarifications for -l to newrole.1

[Stephen Smalley]

On Fri, 2007-01-12 at 10:19 -0600, Michael C Thompson wrote:
> Stephen Smalley wrote:
> <snip>
> > Looks sane as far as content is concerned, although I don't understand
> > the author ordering (I'd typically expect alphabetically by last name or
> > by amount of involvement or by date of involvement).  But it doesn't
> > apply (whitespace damage) for me.   Also, please make the patch -p1
> > appliable from the top of the tree, e.g. result of svn diff
> > policycoreutils.
> 
> I've reordered the authors in alphabetical order, and re-patched with -p1.

Still whitespace damaged. See:
http://mbligh.org/linuxdocs/Email/Clients/Thunderbird

Or just attach it.

BTW, newrole.c also has an Authors list in the comments, so either needs
to be updated or dropped.

> 
> Thanks,
> Mike
> 
> ---
> 
> --- policycoreutils-1.33.12.orig/newrole/newrole.1      2007-01-11 
> 13:01:39.000000000 -0600
> +++ policycoreutils-1.33.12/newrole/newrole.1   2007-01-12 
> 10:15:14.000000000 -0600
> @@ -57,16 +57,45 @@
>   .B --version
>   shows the current version of newrole
>   .PP
> +.SH EXAMPLE
> +.br
> +Changing role:
> +   # id -Z
> +   staff_u:staff_r:staff_t:SystemLow-SystemHigh
> +   # newrole -r sysadm_r
> +   # id -Z
> +   staff_u:sysadm_r:sysadm_t:SystemLow-SystemHigh
> +
> +Changing sensitivity only:
> +   # id -Z
> +   staff_u:sysadm_r:sysadm_t:Unclassified-SystemHigh
> +   # newrole -l Secret
> +   # id -Z
> +   staff_u:sysadm_r:sysadm_t:Secret-SystemHigh
> +
> +.PP
> +Changing sensitivity and clearance:
> +   # id -Z
> +   staff_u:sysadm_r:sysadm_t:Unclassified-SystemHigh
> +   # newrole -l Secret-Secret
> +   # id -Z
> +   staff_u:sysadm_r:sysadm_t:Secret
> +
>   .SH FILES
>   /etc/passwd - user account information
>   .br
>   /etc/shadow - encrypted passwords and age information
> +.br
> +/etc/selinux/<policy>/contexts/default_type - default types for roles
> +.br
>   .SH SEE ALSO
> -.B su
> -(1),
> -.B runas
> +.B runcon
>   (1)
>   .SH AUTHORS
>   .nf
> -Tim Fraser (tfraser@tislabs.com)
> -Anthony Colatrella (amcolat@epoch.ncsc.mil)
> +Anthony Colatrella
> +Tim Fraser
> +Steve Grubb <sgrubb@redhat.com>
> +Darrel Goeddel <DGoeddel@trustedcs.com>
> +Michael Thompson <mcthomps@us.ibm.com>
> +Dan Walsh <dwalsh@redhat.com>
-- 
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: [RFC] clarifications for -l to newrole.1

[Russell Coker]

On Saturday 13 January 2007 01:36, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > MCS as currently released in Red Hat and Debian only uses the high level.
> >  MCS will always use the high level as the main access control mechanism.
> > Therefore this behaviour gets in the way for MCS.
> >
> > Maybe we should have newrole determine whether MCS or MLS is being used
> > and alter it's behaviour accordingly?
>
> Under MCS, IIUC, one never switches the level on a process; your
> sensitivity (low) is always set to SystemLow and your clearance (high)
> is just set to your authorized category set at login, and you manually
> use chcat or similar commands to label files with categories.  So you
> wouldn't use newrole -l at all under MCS.

That's the way it currently works.  I want to change that however, I hope to 
get such changes in Debian soon.

-- 
russell@coker.com.au
http://etbe.blogspot.com/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
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: [RFC] clarifications for -l to newrole.1

[Michael C Thompson]

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

Stephen Smalley wrote:
> On Fri, 2007-01-12 at 10:19 -0600, Michael C Thompson wrote:
>> Stephen Smalley wrote:
>> <snip>
>>> Looks sane as far as content is concerned, although I don't understand
>>> the author ordering (I'd typically expect alphabetically by last name or
>>> by amount of involvement or by date of involvement).  But it doesn't
>>> apply (whitespace damage) for me.   Also, please make the patch -p1
>>> appliable from the top of the tree, e.g. result of svn diff
>>> policycoreutils.
>> I've reordered the authors in alphabetical order, and re-patched with -p1.
> 
> Still whitespace damaged. See:
> http://mbligh.org/linuxdocs/Email/Clients/Thunderbird
> 
> Or just attach it.

Bugger, that's what I normally do, but thought this would be ok... guess 
not :)

> BTW, newrole.c also has an Authors list in the comments, so either needs
> to be updated or dropped.

Added the names that are in the man page, I'm not sure if its 100% or 
not, but its included with the patch.

Thanks,
Mike

---


[-- Attachment #2: newrole-man_author.patch --]
[-- Type: text/x-diff, Size: 2251 bytes --]

diff -Naur policycoreutils-1.33.12.orig/newrole/newrole.1 policycoreutils-1.33.12/newrole/newrole.1
--- policycoreutils-1.33.12.orig/newrole/newrole.1	2007-01-11 13:01:39.000000000 -0600
+++ policycoreutils-1.33.12/newrole/newrole.1	2007-01-12 10:15:14.000000000 -0600
@@ -57,16 +57,45 @@
 .B --version
 shows the current version of newrole
 .PP
+.SH EXAMPLE
+.br
+Changing role:
+   # id -Z
+   staff_u:staff_r:staff_t:SystemLow-SystemHigh
+   # newrole -r sysadm_r
+   # id -Z
+   staff_u:sysadm_r:sysadm_t:SystemLow-SystemHigh
+
+Changing sensitivity only:
+   # id -Z
+   staff_u:sysadm_r:sysadm_t:Unclassified-SystemHigh
+   # newrole -l Secret
+   # id -Z
+   staff_u:sysadm_r:sysadm_t:Secret-SystemHigh
+
+.PP
+Changing sensitivity and clearance:
+   # id -Z
+   staff_u:sysadm_r:sysadm_t:Unclassified-SystemHigh
+   # newrole -l Secret-Secret
+   # id -Z
+   staff_u:sysadm_r:sysadm_t:Secret
+
 .SH FILES
 /etc/passwd - user account information
 .br
 /etc/shadow - encrypted passwords and age information
+.br
+/etc/selinux/<policy>/contexts/default_type - default types for roles
+.br
 .SH SEE ALSO
-.B su
-(1),
-.B runas
+.B runcon
 (1)
 .SH AUTHORS
 .nf
-Tim Fraser (tfraser@tislabs.com) 
-Anthony Colatrella (amcolat@epoch.ncsc.mil)
+Anthony Colatrella
+Tim Fraser
+Steve Grubb <sgrubb@redhat.com>
+Darrel Goeddel <DGoeddel@trustedcs.com>
+Michael Thompson <mcthomps@us.ibm.com>
+Dan Walsh <dwalsh@redhat.com>
diff -Naur policycoreutils-1.33.12.orig/newrole/newrole.c policycoreutils-1.33.12/newrole/newrole.c
--- policycoreutils-1.33.12.orig/newrole/newrole.c	2007-01-11 13:01:39.000000000 -0600
+++ policycoreutils-1.33.12/newrole/newrole.c	2007-01-14 13:56:41.000000000 -0600
@@ -36,8 +36,14 @@
  * setuid root, so that it can read the shadow passwd file.
  * 
  *
- * Authors:  Tim Fraser , 
- *           Anthony Colatrella <amcolat@epoch.ncsc.mil>
+ * Authors:
+ *      Anthony Colatrella <amcolat@epoch.ncsc.mil>
+ *	Tim Fraser
+ *	Steve Grubb <sgrubb@redhat.com>
+ *	Darrel Goeddel <DGoeddel@trustedcs.com>
+ *	Michael Thompson <mcthomps@us.ibm.com>
+ *	Dan Walsh <dwalsh@redhat.com>
+ *
  * Various bug fixes by Stephen Smalley <sds@epoch.ncsc.mil>
  *
  *************************************************************************/