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: Rule Set Based Access Control (RSBAC)
From: Amon Ott <ao_at_rsbac.org>
Date: Fri, 6 Apr 2001 08:48:39 +0200
Here we come to argumenting. I will give you some more documented restrictions and some examples for these models.
> 1) Privacy Model (PM) The definition and assignment of roles and types must be done by two PM roles working together, and that within a given time limit. These roles are first Data Protection Officer and second Security Manager. The four-eyes principle is an important base concept in the whole model.
> b) The user may only access data in controlled manner by performing The TP definition and labelling must also be done by two different roles within a given time limit. This time the roles are TP Manager and Security Officer. This further restricts the real access to personal data to a six-eyes process, and everything within time limits measured in seconds.
> c) The purpose of the user's task must correspond to the purpose This might be possible. However, we are already far away from the term 'easy'. And again, definition and assignment of purposes and tasks need two roles working together within a time limit. BTW: Every user can only have one of these roles, or general user or system admin. This additionally enforces the separation. There are some more aspects, like control of information flow, which we could add to this discussion...
> 2) Malware Scan You were talking about 'most RSBAC modules'. No doubt access control can be effectively used to avoid changes to programs or execution of uncontrolled code. But that was not the question here. What, if users must for some reasons be allowed to create or modify executables, e.g. software developers? How will you know, if the modification on behalf of the user was done by malicious code without consent? How about e.g. text documents containing macros? Web pages with Java applets? Perl, Python, bash scripts, where the execution is done by an interpreter, and all you see is a read-open? Still, we can from now on restrict our discussion to access control in the traditional sense, if you want. I agree that MS is not finished, but it mostly lacks a full set of scan strings. The model itself is complete.
> 3) Role Compatibility RC's strong administration settings are sure my main objection. It enables separate administration areas, which can be e.g. used to effectively create separate, but possibly overlapping work groups.
One example:
It is easy to setup an environment with RC, where - both M1 and M2 can create users and add them to one of their workgroup roles (optionally, the creation could be delegated to another role to separate these tasks) - none of them can assign users her own manager role - none of them can change their own role - none of them can access or assign the other one's roles - none of them can assign her own managed roles to a user, who already has oneof the other one's roles - no other role can do anything of the above items - none of them can change access rights of one of their roles. - this setup can be forever fixed - at least, unless the system is restartedwith inactive RC
> There has been published work in that area by Jonathan Tidswell and I will sure some day soon work through some of these papers. You probably know the problem of limited time as well as I do.
> 4) Access Control Lists ACLs can, but need not be discretionary. It depends on the Access Control and Supervisor rights. They make it easy to have independent administrators for separate filesystem areas - without any access for the other administrators. The ACl inheritance scheme with masks and the accumulation of rights from user, several group and role entries are sure difficult to emulate with roles and types - you would need a real lot of them. Again, one important focus lies on separation of duties. With ACL model, every user can maintain her own set of user groups, which can optionally be used by herself or other users for administration. E.g., one user maintains all user groups, and another grants rights for these groups. None can work alone.
One example:
ACL setup: Workgroup leader L defines a private user group. The workgroup's security officer (possibly as member of another private group) has access control to the secret area and defines appropiate rights for this group. Now L can add or remove users to or from the private group, without anybody else's knowledge. L cannot grant individual access to objects. What if L leaves the company? L transfers the private group to her successor, who is now the only one with access to the member list.
> 5) Mandatory Access Controls How dows TE enforce *-property? How many roles and types would TE need to represent all permutations of 253 levels and 64 compartments?
> 6) File Flags There are some special effects, e.g. search_only is only valid for directories, write_only only for files and fifos. You can certainly define a dir and file type for each permutation of FF flags and use all these types. The definition is probably also quite easy, and with proper type names even usable. Inheritance can be emulated by changing the type labels of all affected objects. So I admit that you can emulate this model, but again not easily.
> 7) Auth Do you also have the concept of only certain programs or processes being able to extend the set of accessible user ids, e.g. to enforce proper authentication by only a privileged set of programs (AUTH attribute auth_may_set_cap)? Additionally you can, as intended, use ACL model as an extension of RC model by using role subjects in the ACL entries. You did not claim to be able to emulate a combination of RSBAC models with TE, but combinations are part of the RSBAC framework design. Amon. -- You have received this message because you are subscribed to the selinux 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 Fri 6 Apr 2001 - 06:08:11 EDT |
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |