Security Enhanced Linux
What's New
Frequently Asked Questions
Background
Documents
License
Download
Participating
Mail List
Archives
Remaining Work
Contributors
Related Work
Press Releases
Information Assurance Research
NIARL In-house Research Areas
Mathematical Sciences Program
Sabbaticals
Computer & Information Sciences Research
Technology Transfer
Advanced Computing
Advanced Mathematics
Communications & Networking
Information Processing
Microelectronics
Other Technologies
Technology Fact Sheets
Publications
Related Links
|
SELinux Mailing ListRE: Now that SELinux supports booleans should we replace tunables with booleans?
From: Karl MacMillan <kmacmillan_at_tresys.com>
Date: Wed, 14 Apr 2004 09:11:11 -0400
Why is a reboot required?
> The aim of booleans is for things that are designed to be transient (EG I don't agree completely with this. Booleans allow well defined policy changes to be made by domains without policy compilation and reloading privileges. In order to use the tunables, a user/domain must have full access to change anything about the policy. With the booleans a user can be authorized to change a portion of the policy in a specific way without any other policy privileges. This seems like an important advantage to me.
> Also if we use booleans for tunables we need to have boolean support for There is full support for type transition rules - the current Boolean example (ping.te) in the NSA policy uses the domain_auto_trans macro within a conditional block. It is true that there isn't support for role statements in conditional blocks, but it is not clear that authorizing a role for a type represents is security risk if there are no rules that allow that role to reach the type (again, see the ping.te example - user_r is authorized for ping_t but can only reach it if user_ping is true). Hopefully role and role transition statements will be supported in conditional statements soon, but it doesn't seem like a large reason not to use the booleans for now. As far as preserving boolean values, this doesn't seem any different from other runtime kernel values and there are mechanism that can be easily extended to handle this. Karl
> I think it's best to continue with tunables the way they are.
Karl MacMillan
> -- -- 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.Received on Wed 14 Apr 2004 - 09:11:20 EDT |
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |