On Wed, 2004-09-01 at 12:00, Linas Vepstas linas@austin.ibm.com wrote:
Every now and then, I look at SELinux, and I get scared away by its complexity. This complexity makes it very hard to audit, and assure oneself that its actually providing any real security, as opposed to the illusion of security. During this email thread, there are references to mysterious rules that neither party in the conversation fully understands; this scares me.
This is not the first time I've heard about SELinux complexity. A colleague attended a meeting of the DC area SELinux Users Group and came away repeating stories about 50000 rules that needed to be defined for a typical system. His reaction was "How can you be sure you have done 50000 rules right?". I heard similar talk in the hallway at one of the EGOVOS conferences.
I think the complexity derives from Mandatory Access Control rather than SELinux itself. Thus far almost all of the attention regarding SELinux policies has been given to basic computer infrastructure and basic system administration. Some of the packages in the basic infrastructure have hundreds of files. MAC requires each file in each package to be considered and its access control rules defined. The complexity in the rules is a consequence of the complexity in the infrastructure.
The real issue is the adequacy of tools to manage the complexity.
Furthermore, although SELinux has the mechanisms for defining and enforcing access control rules beyond the basic infrastructure, trying to develop policies based on business process rules and business considerations looks like a daunting task right now. By this I mean roles that get beyond sysadmin and user into areas such as bank teller or hospital primary care provider or control system operations shift supervisor, together with the rules appropriate to those roles in their business contexts.
I think there are people working on tool concepts, but it seems we are a few years away from taming the complexity of MAC and SELinux sufficiently to allow users to easily and confidently define SELinux policies for applications based on business considerations.
Stan Klein
On Fri, 3 Sep 2004 04:25, "Stanley A. Klein" sklein@cpcug.org wrote:
On Wed, 2004-09-01 at 12:00, Linas Vepstas linas@austin.ibm.com wrote:
Every now and then, I look at SELinux, and I get scared away by its complexity. This complexity makes it very hard to audit, and assure oneself that its actually providing any real security, as opposed to the illusion of security. During this email thread, there are references to mysterious rules that neither party in the conversation fully understands; this scares me.
This is not the first time I've heard about SELinux complexity. A colleague attended a meeting of the DC area SELinux Users Group and came away repeating stories about 50000 rules that needed to be defined for a typical system. His reaction was "How can you be sure you have done 50000 rules right?". I heard similar talk in the hallway at one of the EGOVOS conferences.
What about the stories of systems of 130,000 files where the permissions of each file matters? How can you be sure that you have done 130,000 file permissions right? :-#
A minimal Linux install has 130,000 files...
SE Linux has assertion rules to prevent you doing something really stupid. The rule "allow domain shadow_t:file create_file_perms;" will not be compiled because of the assertions. The command "chmod 4777 /bin/foo" can be executed on any typical Unix system.
The SE Linux policy can be analysed with apol or slat. These tools allow you to determine what access is granted from a particular domain. To attempt to perform such analysis of Unix permissions you need to start with a "find /" operation to discover what access is granted. On some systems "find /" is not feasible (I used to run a system where according to my best estimates "find /" would take more than 10 days to complete while hurting system performance enough to get the direct attention of the CEO), in which case analysing the Unix permissions can not be done.
You (as the administrator of a SE Linux system) do not have to write 50,000 rules. Many of the rules in the binary policy are expansions from simple rules in the policy language. A rule such as "allow user_t domain:dir { search getattr read };" may expand to 300 rules (one for each domain) in the policy binary (depending on how many domains are in the policy). Then there's the macro language, if you want to allow user_t to see all domains in the output of "ps" then you use the macro invocation "can_ps(user_t, domain)" which expands to four rules in the policy.conf file which are then multiplied by the 300 domains to give 1200 rules in the policy binary (from one line of source which is easy to verify).
Also 99.99% of the policy is already there and has been well checked. The amount of changes you need to make to the default policy should be rather small and therefore easy to check.
I think the complexity derives from Mandatory Access Control rather than SELinux itself. Thus far almost all of the attention regarding SELinux policies has been given to basic computer infrastructure and basic system administration. Some of the packages in the basic infrastructure have hundreds of files. MAC requires each file in each package to be considered and its access control rules defined. The complexity in the rules is a consequence of the complexity in the infrastructure.
Yes.
The real issue is the adequacy of tools to manage the complexity.
I believe that the tools to manage SE Linux policy are more adequate than the tools to manage Unix permissions.
Furthermore, although SELinux has the mechanisms for defining and enforcing access control rules beyond the basic infrastructure, trying to develop policies based on business process rules and business considerations looks like a daunting task right now. By this I mean roles that get beyond sysadmin and user into areas such as bank teller or hospital primary care provider or control system operations shift supervisor, together with the rules appropriate to those roles in their business contexts.
Why would you need anything special for that? It's just a matter of having a SE Linux role to match the use of the system and some rules to allow access to the appropriate files, databases, etc which are appropriate for that role.
I think there are people working on tool concepts, but it seems we are a few years away from taming the complexity of MAC and SELinux sufficiently to allow users to easily and confidently define SELinux policies for applications based on business considerations.
I agree that there is more work to be done in this area. However people have been using systems based solely on Unix permissions without any such tools for many years.
It would be nice to have a tool to analyse access transitions via SETUID programs on a Unix system in the same way that slat and apol can analyse the SE Linux policy.
selinux@lists.fedoraproject.org
-
Russell Coker -
Stanley A. Klein