| |||||||||||||
|
| |||||||||||||
SELinuxSELinuxPosted Oct 8, 2009 16:09 UTC (Thu) by rahulsundaram (subscriber, #21946)In reply to: SELinux by michaeljt Parent article: LPC: Three sessions from the security track
Here is what I wrote in a FAQ on this topic:
SE(Security Enhanced) Linux is a security feature in the Linux kernel and enabled by default in Fedora that provides more fine grained access control compared to traditional Unix file permissions and user based confinement.
SELinux can confine access of programs within a computer and hence can be conceptually thought of a internal firewall between programs. A centralized policy determines which software can access what resources based on extended attributes/labels associated with files. For example, network services can be confined to a particular port, say Apache web server can be restricted to be able to connect to only 80 by default.
Hope this helps.
(Log in to post comments)
SELinux Posted Oct 8, 2009 21:13 UTC (Thu) by hppnq (subscriber, #14462) [Link] The mandatory Google query "site:lwn.net selinux" turns up a number of well-written articles on SELinux.(Oh, and Apache binds to port 80, clients connect to it. ;-)
SELinux Posted Oct 9, 2009 9:01 UTC (Fri) by michaeljt (subscriber, #39183) [Link]
Thanks for your answer! So if I combine that with what I have already had to find out myself over the past couple of years, does it boil down to the following?
* a mechanism for controlling which operations which may be performed on which files and devices and what networking operations may be performed (plus a few which I am not aware of) based on the current rights assigned to the executing process. * a mechanism for adding or removing rights based on user ID, explicit requests from the user and execution of binaries with the equivalent of special capabilities (again, plus a few which I'm not aware of). * An in-kernel-memory policy database to manage all this.
SELinux Posted Oct 9, 2009 9:39 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
Enforcement of restrictions is based on the policy and labels (MAC) rather than users (DAC). So even programs/process run by the same user can have different rights (access to files, ports etc). This allows for more fine grained access control and this is a key differentiator as it allows a central policy to determine access. Other than that, your understanding seems correct.
SELinux Posted Oct 9, 2009 9:49 UTC (Fri) by michaeljt (subscriber, #39183) [Link]
I take it that restrictions is a more accurate term here that the "rights" I used above? That is, we are talking about "allowed by default"? And does user ID play no role whatsover? I thought that "role" was important, and that there was a mapping of which UIDs could assume which roles. I was thinking of the "policy and labels" applied to executables when I talked about "binaries with the [SELinux] equivalent of capabilities", did I miss something important?
Thanks again :)
SELinux Posted Oct 10, 2009 0:22 UTC (Sat) by janfrode (subscriber, #244) [Link]
No, it's "default deny", so the selinux policy adds permissions to do something.
User ID doesn't matter, except that you'll first need to pass the normal owner/group/permissions before selinux is involved (DAC before MAC).
"Roles" I'm not much familiar with..
|
|
||||||||||||