From: Stephen Smalley <sds@tislabs.com>
Subject: Re: Rule Set Based Access Control (RSBAC)
Date: Wed, 4 Apr 2001 12:31:39 -0400 (EDT)
Next Article (by Author): Re: Rule Set Based Access Control (RSBAC) Stephen Smalley
Previous Article (by Author): Re: Rule Set Based Access Control (RSBAC) Stephen Smalley
Top of Thread: Re: Rule Set Based Access Control (RSBAC) Amon Ott
Next in Thread: Re: Rule Set Based Access Control (RSBAC) Amon Ott
Articles sorted by: [Date]
[Author]
[Subject]
> So does it really e.g. change the access bits on open file descriptors or close > them, when the policy setting that originally granted access is now set so that > access would be denied? For open file descriptions, SELinux simply revalidates permission on use, so it doesn't need to modify the file flags or close the descriptors. The AVC entry references allow SELinux to perform such revalidation without the overhead of a full permission check computation unless the policy has changed. For memory-mapped files, SELinux invalidates the page cache entries for the relevant file and revalidates permission on the subsequent page fault (this support is not yet complete in our 2.4 version). > The fixed RSBAC models were implemented in such a hardwired way, because it > should be conceptually impossible to change them at runtime. Thus I saw no need > for type abstraction, and sure the compiler type checks were useful for coding. But this is contrary to being flexible in the ability to add, remove, or completely replace policy modules in the ADF without affecting the rest of the kernel or applications that deal with labels. > After having another look into RSBAC code: The only such pointer really used is > the dentry pointer. How do you handle attribute value inheritance in > filesystems? Do you have such a concept? > > Inheritance is an important RSBAC concept, because it greatly reduces the > number of attribute structs ('labels') and makes administration easier. By inheritance, do you simply mean the behavior when a file is created and initially assigned a label or do you mean an implicit labeling mechanism similar to the implicit typing of DTE? SELinux stores file labels explicitly, but it allows labels to be managed using a higher-level specification based on pathname regular expressions. We support inheritance of attributes when files are created, but each file has its own label. However, the technique used to store those labels only needs to store each distinct label once. > Not having to change the tool is sure an advantage, but policy independent ps > output must somehow be connected to the policy afterwards to be of any use, or > am I mistaken here? How is this problem handled? Sure you are not just moving > it to the administrators. The two policy-independent data types for security labels are the security context and the security identifier (SID). The security context is simply a human-readable string representation of the security attributes, while the security identifier is simply a nonpersistent, local integer that refers to a security context. Applications such as the modified ps can simply handle and display security contexts without needing to deal with the internal content and format of such contexts. The file system code can likewise handle and store security contexts for persistent labels (using an intermediate mapping of persistent security identifiers for efficiency) without needing to deal with the internals of labels. Most of the kernel can simply deal with SIDs for active subjects and objects. So you can add or remove attribute fields or completely replace the security label format/contents without any impact on applications or kernel code that deals with labels. > We still seem to have some difference in the way we look at security models: > For me, labelling by a subject should be an exception from the rule, because it > is a discretionary element. Whenever possible, the labels should be mandatory, > chosen by predefined security settings, which are done with as much separation > of duty as possible. > > Something special in my point of view is that I distrust all user mode > programs, because they come from unknown sources and might have been modified, > e.g. trojanized or infected by viruses. In some cases I have to rely on them, > e.g. for the (insuffient) Linux style user authentication. I don't think we really disagree here. As much as possible, we try to provide complete transparency to applications through default labeling behaviors. But we also believe that there are valid reasons for providing extended APIs to certain applications. Providing those extended APIs doesn't weaken our security, because a single set of consistent controls is defined that addresses both the ordinary calls and the extended calls. > But here you interfere with the existing Linux access control scheme, which > might want to set the capabilities differently. > Or are you only talking about the place of interception of the object access? > Then you have a point here, it could really reduce the modifications, but it > gives you less data to decide upon. In addition to our other controls, we provide a parallel "interception"/control for each of the Linux capabilities that is implemented in the existing capable function. That allow us to leverage what the Linux-Privs people have done to trivially control a number of privileged operations. We aren't interfering with the Linux capabilities scheme any more than we are interfering with the Linux DAC scheme - we simply provide an additional, orthogonal control that must also authorize the operation. > How do you authenticate and set another id then? Do you provide modified > programs with extra calls for all such cases? We provide a slightly modified login program to set the initial security context for the user's login session. Alternatively, we could have left login alone and provided a new program for authenticating and setting our user identity after login, but it was cleaner to modify login. Otherwise, we don't care about changes in the Linux identity attributes during a login session - they aren't relevant to our controls. > And you are sure you do not want to use ACLs instead? How do you keep the > overview over 70 domains and filesystems with 188 file types? > How many domains are for single users only? Most of the domains are simply for the various system daemons and for programs that require special access rights. For example, we define domains for init, the rc scripts, getty, syslogd, klogd, crond, login, inetd, tcpd, ftpd, etc. For some programs, we define multiple domains depending on the context in which they were called, e.g. login runs in different domains with different permissions depending on whether it was executed by getty, rlogind, or sshd. Programs that require special access rights like insmod or fsck are placed into their own domains, and we restrict the ability to enter these domains. For users, we currently just define two initial login domains, one for ordinary users and one for administrators. However, as users run programs, these domains automatically transition to derived domains as needed to gain or shed access rights. For example, when users run netscape, they transition to a less privileged domain so that any downloaded code is confined. When users run passwd, they transition to a more privileged domain that can modify the passwd file. > Out of interest: How is your binary policy representation protected against > unwanted modification? In the same way that any other file is protected - by labeling appropriately and defining the policy so that write access is highly restricted. -- Stephen D. Smalley, NAI Labs ssmalley@nai.com - To unsubscribe from the rsbac list, send a mail to majordomo@rsbac.org with unsubscribe rsbac as single line in the body.
Next Article (by Author): Re: Rule Set Based Access Control (RSBAC) Stephen Smalley
Previous Article (by Author): Re: Rule Set Based Access Control (RSBAC) Stephen Smalley
Top of Thread: Re: Rule Set Based Access Control (RSBAC) Amon Ott
Next in Thread: Re: Rule Set Based Access Control (RSBAC) Amon Ott
Articles sorted by: [Date]
[Author]
[Subject]