I just received a question about SE Linux via email. As I don’t want to post private messages containing material that’s globally useful I’ll answer through my blog:
> other than strict and targeted policies……other policies like
> RBAC, MCS, Type Enforcement are also there….how are these policies
> implemented
The two main policies are the strict policy and the targeted policy. The strict policy is the earliest and was originally known as the sample policy (but was given the name “strict” after targeted was developed).
The strict policy aims to give minimal privileges to all daemons. The targeted policy aims to restrict the programs that are most vulnerable (network facing daemons) and not restrict other programs (for ease of use). There is currently work in progress on combining those policies so the person who compiles the policy can determine which features of strict they desire.
RBAC means Role Based Access Control. The strict policy assigns users to roles and the role then limits the set of domains that can be entered. For example the user_r role does not permit the sysadm_t domain so a user who is only permitted to enter the user_r role can not perform sys-admin tasks. Like many terms RBAC is used in different manners, some people consider that it means direct control by role (EG role user_r can not write to /dev/hda), while SE Linux has a more indirect use of roles (role user_r can not run programs in domain sysadm_t or any other domain that allows writing to type fixed_disk_device_t – the type for /dev/hda). You may consider that the strict policy supports RBAC depending on which definition of the term you use.
Generally the targeted policy is not considered to support RBAC, although if you consider a role to merely be a container for a set of accesses that are permitted then a SE Linux domain could be considered a in the RBAC sense. I don’t think of targeted policy as being a RBAC implementation because all user sessions run in the domain unconfined_t which has no restriction. I think that to be considered RBAC a system must confine user logins.
Type enforcement is the primary access control mechanism for SE Linux. Every object that a process may access (including other processes) has a type assigned to it. The type of a process is known as a domain. The system has a policy database which for every combination of domain, type, and object class (which is one of dir, file, blk_file, etc – all the different types of object that a process may access) specifies whether the action is permitted or denied (default deny) and whether it is audited (default is to audit all denied operations and not audit permitted operations).
MCS is a confidentiality protection mechanism where each file has a set of categories assigned to it. The set may be empty, may contain all 1024 categories, or any sub-set. Each process has a set of categories that determines which files it may access. File access is granted if Unix permissions allow it, if the domain-type model allows it, and if MCS allows it (on an MCS system). I have just had an article on MCS published in Linux Journal.
MCS is an optional feature for people compiling Linux from source or for distribution vendors. For Red Hat Enterprise Linux, Fedora, and Debian the decision was made to include it, so the strict and targeted policies for those distributions include MCS.
There is another policy known as MLS. This is a policy build that comprises the strict policy plus Multi-Level Security. Multi-Level Security aims to give the highest confidentiality protection and comply with the LSPP (Labeled Security Protection Profile – roughly comparable to B1) Common Criteria certification. It would be possible to build a targeted policy with MLS but that wouldn’t make sense – why have the highest protection of confidentiality with anything less than the highest protection of integrity?
As for how the policies are implemented, I’m not about to write a tutorial on policy writing for a blog post, I’m sure that someone will post a link to a Tresys or Fedora web page in the comments. ;)
> there r some packages of linux in which some changes has been made
> to support linux……for eg:- coreutils, findutils
That is correct. Every program that launches a process on behalf of a user at a different privilege user (EG /bin/login, sshd and crond) and every program that creates files for processes running in different domains (EG logrotate creating new log files for multiple daemons) needs to be modified to support SE Linux. Also ls and ps were modified to show SE Linux contexts as well as the obvious programs in coreutils.
> ‘Z’ is the new thing that have been added to most of the
> utilities……wherever I search I get the changes made only in few
> utilities like ps, mv, cp, ls
>
> Can u help me by giving all the changes made in each of the utilities…..
Unfortunately I can’t. This has been identified as an issue and there is currently work in progress to determine the best way of managing this.