clarifications for -l to newrole.1
RFC 1/1 clarifications for -l to newrole.1
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 2007-01-11 14:31:51.000000000 -0600 renamed from newrole.1.orig 2007-01-11 14:24:51.000000000 -0600 +15 -0
@@ -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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 5 lines · 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.
Quoted 7 lines
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?
Quoted 6 lines
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.
Signature · 8 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 25 lines · Stephen Smalley
Quoted 5 lines · 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.
Quoted 7 lines
EXAMPLE
Changing sensitivity only:
# id -Z
user:role:type:SystemLow-SystemHigh
# newrole -l Unclassified
# id -Z
user:role:type:Unclassified-SystemHighHow 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?
Quoted 6 lines
Changing sensitivity and clearance:
# id -Z user:role:type:SystemLow-SystemHigh # newrole -l Unclassified-Unclassified # id -Z user:role:type:Unclassified-Unclassified
Quoted 7 lines
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
Signature · 8 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 11 lines · Stephen Smalley
Quoted 7 lines
EXAMPLE
Changing sensitivity only:
# id -Z
user:role:type:SystemLow-SystemHigh
# newrole -l Unclassified
# id -Z
user:role:type:Unclassified-SystemHighHow 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.
Quoted 9 lines
Quoted 6 lines
Changing sensitivity and clearance:
# id -Z user:role:type:SystemLow-SystemHigh # newrole -l Unclassified-Unclassified # id -Z user:role:type:Unclassified-UnclassifiedWhen 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?
Quoted 4 lines
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.
Signature · 9 lines
[email protected] 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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 9 lines · Russell Coker
Quoted 8 lines · Stephen Smalley
Quoted 7 lines
EXAMPLE
Changing sensitivity only:
# id -Z
user:role:type:SystemLow-SystemHigh
# newrole -l Unclassified
# id -Z
user:role:type:Unclassified-SystemHigh
Quoted 6 lines
Quoted 3 lines
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).
Quoted 10 lines
Quoted 9 lines
Quoted 6 lines
Changing sensitivity and clearance:
# id -Z user:role:type:SystemLow-SystemHigh # newrole -l Unclassified-Unclassified # id -Z user:role:type:Unclassified-UnclassifiedWhen would you envision a user doing the above? Trying to ensure that any process he subsequently starts cannot escalate to higher levels?
Quoted 6 lines
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.
Quoted 11 lines
Quoted 4 lines
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.
Signature · 8 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 15 lines · Stephen Smalley
Quoted 8 lines · Russell Coker
Quoted 7 lines · Stephen Smalley
Quoted 7 lines
EXAMPLE
Changing sensitivity only:
# id -Z
user:role:type:SystemLow-SystemHigh
# newrole -l Unclassified
# id -Z
user:role:type:Unclassified-SystemHighQuoted 5 lines
Quoted 3 lines
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.
Quoted 7 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 6 lines · --- Michael C Thompson
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
[email protected]
--
This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 22 lines · Casey Schaufler
Quoted 6 lines · --- Michael C Thompson
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
Quoted 8 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 3 lines · --- Joe Nall
On HP-UX 10.26, normal users can login at syslo, which in our systems
corresponds to unclassified.
Hmm.
Quoted 3 lines
There is no special effort made to use
MLS to protect the TCB (some files are syshi because of their contents).
Hmm.
Quoted 2 lines
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 gettingMINT_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
[email protected]
--
This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 24 lines · Michael C Thompson
Quoted 15 lines · Stephen Smalley
Quoted 8 lines · Russell Coker
Quoted 7 lines · Stephen Smalley
Quoted 7 lines
EXAMPLE
Changing sensitivity only:
# id -Z
user:role:type:SystemLow-SystemHigh
# newrole -l Unclassified
# id -Z
user:role:type:Unclassified-SystemHighQuoted 5 lines
Quoted 3 lines
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.
Quoted 7 lines
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).
Quoted 3 lines
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.
Signature · 8 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 4 lines · Stephen Smalley
Quoted 4 lines
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.
Quoted 8 lines
Quoted 2 lines
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.
Signature · 9 lines
[email protected] 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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 14 lines · Stephen Smalley
Quoted 5 lines · 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.
Quoted 7 lines
EXAMPLE
Changing sensitivity only:
# id -Z
user:role:type:SystemLow-SystemHigh
# newrole -l Unclassified
# id -Z
user:role:type:Unclassified-SystemHigh
Quoted 3 lines
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.
Quoted 9 lines
Quoted 6 lines
Changing sensitivity and clearance:
# id -Z user:role:type:SystemLow-SystemHigh # newrole -l Unclassified-Unclassified # id -Z user:role:type:Unclassified-UnclassifiedWhen 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".
Quoted 4 lines
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.
Quoted 4 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 33 lines · Stephen Smalley
Quoted 5 lines · 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.
Quoted 7 lines
EXAMPLE
Changing sensitivity only:
# id -Z
user:role:type:SystemLow-SystemHigh
# newrole -l Unclassified
# id -Z
user:role:type:Unclassified-SystemHighHow 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?
Quoted 6 lines
Changing sensitivity and clearance:
# id -Z user:role:type:SystemLow-SystemHigh # newrole -l Unclassified-Unclassified # id -Z user:role:type:Unclassified-UnclassifiedWhen 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).
Quoted 4 lines
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 2007-01-11 17:57:06.000000000 -0600 renamed from newrole.1.orig 2007-01-11 14:24:51.000000000 -0600 +34 -5
@@ -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 ([email protected]) -Anthony Colatrella ([email protected]) +Dan Walsh <[email protected]> +Steve Grubb <[email protected]> +Darrel Goeddel <[email protected]> +Michael Thompson <[email protected]> +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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 89 lines · Michael C Thompson
Quoted 33 lines · Stephen Smalley
Quoted 5 lines · 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.
Quoted 7 lines
EXAMPLE
Changing sensitivity only:
# id -Z
user:role:type:SystemLow-SystemHigh
# newrole -l Unclassified
# id -Z
user:role:type:Unclassified-SystemHighHow 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?
Quoted 6 lines
Changing sensitivity and clearance:
# id -Z user:role:type:SystemLow-SystemHigh # newrole -l Unclassified-Unclassified # id -Z user:role:type:Unclassified-UnclassifiedWhen 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).
Quoted 4 lines
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 2007-01-11 17:57:06.000000000 -0600 renamed from newrole.1.orig 2007-01-11 14:24:51.000000000 -0600 +28
-3@@ -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)
newrole.1 2007-01-11 17:57:06.000000000 -0600 line 101
Quoted 10 lines
newrole.1 2007-01-11 17:57:06.000000000 -0600 renamed from newrole.1.orig 2007-01-11 14:24:51.000000000 -0600 +6
-2.SH AUTHORS .nf -Tim Fraser ([email protected]) -Anthony Colatrella ([email protected]) +Dan Walsh <[email protected]> +Steve Grubb <[email protected]> +Darrel Goeddel <[email protected]> +Michael Thompson <[email protected]> +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.
Signature · 8 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Stephen Smalley wrote:
<snip>
Quoted 6 lines
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
---
newrole/newrole.1 2007-01-12 10:15:14.000000000 -0600 renamed from newrole/newrole.1 2007-01-11 13:01:39.000000000 -0600 +34 -5
@@ -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 ([email protected]) -Anthony Colatrella ([email protected]) +Anthony Colatrella +Tim Fraser +Steve Grubb <[email protected]> +Darrel Goeddel <[email protected]> +Michael Thompson <[email protected]> +Dan Walsh <[email protected]>
--
This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 10 lines · Michael C Thompson
Stephen Smalley wrote:
<snip>Quoted 6 lines
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.
Quoted 61 lines
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 -0600newrole/newrole.1 2007-01-12 10:15:14.000000000 -0600 renamed from newrole/newrole.1 2007-01-11 13:01:39.000000000 -0600 +34
-5@@ -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 ([email protected]) -Anthony Colatrella ([email protected]) +Anthony Colatrella +Tim Fraser +Steve Grubb <[email protected]> +Darrel Goeddel <[email protected]> +Michael Thompson <[email protected]> +Dan Walsh <[email protected]>
Signature · 8 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 9 lines · Stephen Smalley
Quoted 8 lines · Michael C Thompson
Stephen Smalley wrote:
<snip>Quoted 6 lines
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.
Quoted 6 lines
Quoted 1 line
I've reordered the authors in alphabetical order, and re-patched with -p1.
Still whitespace damaged. See:
http://mbligh.org/linuxdocs/Email/Clients/ThunderbirdOr just attach it.
Bugger, that's what I normally do, but thought this would be ok... guess not :)
Quoted 2 lines
BTW,
newrole.calso 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
---
newrole/newrole.1 +34 -5
@@ -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 ([email protected]) -Anthony Colatrella ([email protected]) +Anthony Colatrella +Tim Fraser +Steve Grubb <[email protected]> +Darrel Goeddel <[email protected]> +Michael Thompson <[email protected]> +Dan Walsh <[email protected]>
newrole/newrole.c +8 -2
@@ -36,8 +36,14 @@* setuid root, so that it can read the shadow passwd file. * * -* Authors: Tim Fraser , -* Anthony Colatrella <[email protected]> +* Authors: +* Anthony Colatrella <[email protected]> +* Tim Fraser +* Steve Grubb <[email protected]> +* Darrel Goeddel <[email protected]> +* Michael Thompson <[email protected]> +* Dan Walsh <[email protected]> +* * Various bug fixes by Stephen Smalley <[email protected]> * *************************************************************************/