The reason is simple. Most of us working on SELinux are developers. We don’t like writing documentation. We’d rather write blog entries explaining some aspect of SELinux instead of real documents. While this works when your primary audience are knowledgeable enough to find the blog entries, figure out how to apply the concepts to their problems and connect all the dots between here and there it isn’t useful for new users or users trying to solve a simple problem.

It is unfortunate, and some people over the years have helped us out, such as with the Fedora SELinux User Guide, but unfortunately we’ve missed some users, particularly new ones, and we haven’t aggregated these documents onto a distribution agnostic place with good organization.

With that in mind I volunteered to start the SELinux Documentation Project during LPC. Basically the goal is to make user-problem focused documentation available at the official SELinux project site. This will be a huge effort, writing original documentation, organizing it into consumable chunks and mining years of mail list posts, blog entries and other resources to deliver documents to users.

I’ve already started putting up several pieces. One of the things I want to really focus on are SELinux ‘recipes’, short, to-the-point blurbs telling users how to do the things they want to do, like allowing apache to connect to their database server, or  how to easily add a rule to their policy.

We also need a place where potential developers can go to easily get resources on developing SELinux so that our community can expand. Further a place where vendors can go to learn about what SELinux can do for their solution and how to get started using SELinux is a must.

All that said, I can’t do this alone. I’ve started several pages and will continue doing so but if you are one of those strange souls with a propensity to document things, or you have recently gone through the pains of finding info in obscure places that you couldn’t find elsewhere we could really use your help in expanding, organizing and centralizing documentation on selinuxproject.org. If you want to help you can email me at method at manicmethod.com or James Morris at jmorris at namei.org to get an account and start contributing.

Wow, I just noticed it’s been a year since I’ve blogged, that is not good.

That doesn’t mean nothing has been going on though, we’ve been quite busy around here.

I’d like to talk about a couple projects we are working on. The first is better integration of SELinux policies into RPM. We’ve posted a patch set to the rpm-maint mailing list and are awaiting feedback. To try out the patches yourself you can read the instructions on the project page at selinuxproject.org.

The current patch set basically makes RPM actually do stuff with the %policy tag, which it never did before. We’ve also changed the %policy tag to be more flexible in allowing more information about the policies to be handled by RPM, such as policy modules that are being obsoleted. You can read the full description of the patches on the mail list postings.

This is only the first step in a long term project we have to make RPM more robust and reduce the amount of trust necessary in the package manager. We have several ideas of how to proceed but we haven’t proven that they’ll work yet (or that the RPM community will be interested in them). Suffice to say we basically want to break RPM into smaller pieces, each of which has a dedicated job to do, which can be confined by SELinux. Each step would require less trust that the packages aren’t malicious and that the SELinux policy is correct and will enforce the security goals set forth by the packager. Once this is done we want to try running core parts of RPM in different security domains depending on different attributes about the package and who is running it, such as what certificates were used to sign the package, where the package came from, who is running RPM and so on.

The culmination of this effort would be to be able to download a 3rd party package and install it knowing that it will only be able to add its files to /opt, and not modify anything in /usr, /lib, /etc, etc. Further the scriptlets should be confined so that they can’t add users to the system or any other security critical activities. This will be a truly exciting capability for Linux systems moving forward.

I delivered a presentation on this project at Linux Plumbers Conference last month in Portland. The slides and video recording are published on the web for those who are interested.

I’ll talk about another project we are working on in my next blog post, which should be coming pretty soon.

It didn’t get nearly as many answers as What’s your favorite “programmer” cartoon but I did get mostly good feedback, it seems like the audience on stackoverflow, in general, have seen the positive progress of SELinux and many have chosen to keep it enabled (or even write policies and make it work for them).

Good to hear!

The policy installed with Ubuntu is fairly limited. It is a very small base policy with a cups module available. This was the result of Ubuntu politics but obviously I wanted something more comprehensive. The first thing I did was grab the reference policy from oss.tresys.com and try to figure out what policies I wanted installed. Reference policy has 259 modules and I didn’t want all of them. 

I took the Gentoo policy ebuild to start, since it is a much smaller policy than Fedora has and I added modules for the services I was going to run. The result (for now) is this:

application = base
authlogin = base
bootloader = base
clock = base
consoletype = base
corecommands = base
corenetwork = base
cron = base
devices = base
dmesg = base
domain = base
files = base
filesystem = base
fstools = base
getty = base
hostname = base
hotplug = base
init = base
iptables = base
kernel = base
libraries = base
locallogin = base
logging = base
miscfiles = base
mls = base
mcs = base
modutils = base
mount = base
mta = base
netutils = base
nscd = base
raid = base
selinux = base
selinuxutil = base
ssh = base
staff = base
storage = base
su = base
sysadm = base
sysnetwork = base
terminal = base
udev = base
unconfined = base
userdomain = base
usermanage = base
unprivuser = base
 
dovecot = module
postfix = module
bind = module
mysql = module
apache = module
dpkg = module
spamassassin = module
ntp = module

This is a relatively small policy, yeilding a 500k policy.23. 

Then I ran in to my first problem. The SELinux libraries installed on Hardy won’t build the most recent reference policy due to a bug that was fixed after Ubuntu’s libraries were built. So I had to upgrade my libraries and policy compiler. Since I normally develop on Fedora I assumed I could grab some sort of source deb, update the code and rebuild it. I couldn’t figure out how to do that though, all of the source pointers go to the developers repository which looked just like the upstream source. I have no idea how to build debs so I gave up and just built from the selinux userspace git tree. 

After getting a toolchain I could build the policy on and building and installing the policy I relabeled the filesystem and tried rebooting. Thats when the second problem happened. I couldn’t log in via ssh (doh!) and the server is located alot of miles away (like 1000 or something). Good thing the machine has a remote administration console. So I logged in via that and took a look at ps -AZ to see what was going on (I was certain that ssh was running in the wrong context and that is why I couldn’t log in, even in permissive). Everything was running in sysadm_t !?! This was pretty baffling to me, I did some sesearch’s on the policy (btw, the setools package pulls in the whole thing which requires gtk, tcl, tk, whatever.. too bad there isn’t a setools-console package). Well it turns out that if the upstart_init boolean isn’t set to true then initrc_t transitions to sysadm_t on shell_exec_t, I have no clue why, very strange. Set the boolean and everything looks good (yay).

Now everything is up and running in the right context (well, mostly everything, mysqld_safe, logger and dd (run for klogd apparently) are running in initrc_t, which is effectively unconfined) I’ll work on those later.

Right now I’m getting tons of denials, most are related to having a tmpfs /var/run I think, also udev is doing all sorts of crazy things (but then again doesn’t it always). Hopefully I’ll get these taken care of and I’ll write another article about the success (assuming I succeed and don’t give up )

I’ve gone over Multi-Level Security (MLS) a little bit before. It’s basically a security policy that is implemented by many trusted operating systems (such as Trusted Solaris) that is hierarchical and inflexible by nature. Specifically Bell-LaPadula (BLP) is used by many operating systems because it reflects the real world security policy used by the government and military. In BLP subjects and objects have a label consisting of a level (Secret, Top Secret, Unclassified, etc) and a set of non-hierarchical categories (US Only, Army, etc).

The sensitivies are hierarchical in that a higher sensitivity process labeled top secret can read and write top secret objects but only read unclassified objects. This prevents the ‘downgrade’ of classified information. For systems that conform to this kind of policy it makes perfect sense, a multi-level desktop system allows users to keep top secret and unclassified material on the same system but does not allow the release of top secret data to unclassified environments or users. Lower levels can also write to higher levels, in some cases. This may seem bad but considering what the policy is trying to accomplish allowing an unclassified process to write a top secret document doesn’t disclose top secret data. The catch is that the unclassified process would never be able to read the document after writing it. This policy is only usable for confidentiality, to prevent information from being released inappropriately. It cannot address integrity or other security goals I have mentioned in other articles.

Because traditional trusted operating systems only implemented BLP (and in some rare cases Biba for integrity) the users of such systems (primarily government and military) had to use it even when it wasn’t appropriate. One such case is a guard, or cross domain solution (CDS). A CDS is a system that allows two or more networks of differing security properties to be connected to one another. A typical CDS can connect a top secret to a secret network, for example, and allow information from the secret network onto the top secret network but not vice versa. CDS’s also do the opposite, allowing a controlled release of information from top secret to secret, or between two coalition networks (Such as Australia and the US). CDS’s always have some safety mechanism built in to prevent malicious data, or inappropriate data from going across it (if it didn’t it wouldn’t be any more useful than a crossover cable between the networks). These safety mechanisms are virus scanners, “dirty word” filters, document disassemblers (for example to take a word document and convert it to plain text or pdf), etc. The type of safety mechanism primarily depends on what kinds of networks the system is connecting.

For now we’ll talk about the first case, letting information flow from a secret network to a top secret network. Since a BLP system is designed to let information go from secret to top secret already it seems like an obvious fit, right? If the CDS was a very simple system with a process to read incoming data, a virus filter and an outgoing process it seems like a BLP policy would be fine. We are going to call the set of processes that pass data through the system the pipeline.

Wrong, there are actually multiple issues here. Because the lower levels would be allowed to write to higher levels, but not read from them we could label the incoming process Unclassified, the middle process Secret and the outgoing process Top Secret. This allows flow from the incoming process to the outgoing process. The main problem here is that since the levels are hierarchical there is nothing that stops the Unclassified process from writing directly to the Top Secret process (oops). Well, people figured this out and thought of a great work-around. Remember those categories? Categories allow reading and writing when the subject dominates (or has a superset) the categories of the object. So you give the incoming process categories that dominate the categories of the middle process but not the outgoing process.

So that problem is solved (albeit in an interesting way) but CDS’s are never that simple (I mean never). The requirements that are imposed on CDS’s specify pesky little things like logging, auditing, monitoring, emergency shutdown, etc. So now our simple CDS needs all processes to be able to talk to a logging system, and a monitoring system must ask the processes for their state and get back a response. So now we have one or more huge processes that can talk to and receive data from every process in the pipeline. That wouldn’t be so bad except the functional requirements of every guard I’ve seen says that those logs have to end up on the high side for consumption, which is obvious, they certainly can’t go to the low side because that would be a violation of the security policy. This, of course, allows information to flow through the logging and monitoring process out the other side without going through the set of filters. Sure, the advocates will say the logging and monitoring system is part of the TCB (Trusted Computing Base), the part of the system that is trusted to not do nasty things, but in a system like this do you want such processes to be trusted?

The above (totally professionally done) diagram shows the attack vector that would be used to get data through such a system. Because the logging/monitoring app is allowed to violate the MAC policy it is possible to use it to bypass filters 2, 3 and 4.

So basically its impossible to use a BLP policy on a guard and ensure that all data is passed through all filters before it reaches the other side, the policy simply wasn’t made for that kind of thing. It has been the standard operating procedure to shoehorn CDS’s into that policy for a very long time, however.

Before I get into how SELinux helps this I’ll quickly cover the other two types of guards I previously mentioned. First the High-to-Low guard. This kind of guard basically allows controlled downgrading of information; it will run filters like a ‘dirty word’ filter to ensure nothing that shouldn’t be getting downgraded isn’t. It may also redact some data. This CDS is a direct violation of the BLP policy, as such the processes essentially have to be MAC Exempt, or not subject to the policy, essentially making the existence of the policy irrelevant, it should be easy to see why this is an inappropriate use of BLP. The second was a CDS between two coalition partners. In this case the BLP policy doesn’t even mean anything since there is no high side and low side, merely ‘different’ sides.

So, those are the reasons why BLP is inappropriate for CDS’s, why is SELinux different?

SELinux primarily uses type enforcement for policy decisions. Type enforcement allows fine grained policy to be written for all subjects and objects on the system. In the case of CDS’s you can literally say incoming process can write to virus scanner (but not read) and virus scanner can write to outgoing process. We call this an assured pipeline. This can be used for any size or type of pipeline, we even have a tool called CDS Framework that lets you visualize the CDS system. But wait, what about all that logging and auditing and monitoring? Simple, since the policy can describe arbitrary relationships between processes we can break that logging and monitoring process up into filter size chunks, then allow each filter to read and write from the logging and monitoring app. The logging and monitoring app can then send its logs through the same pipeline as the data, it will end up on the high side but there is no additional large process you have to trust to allow it to happen. Using type enforcement we can ensure that every single bit of information that comes leaves the guard passed through every filter (we can’t, of course guarantee that the filters worked). Since type enforcement is not hierarchical the direction of the CDS doesn’t matter, we can do the same thing for High-to-Low that we do for Low-to-High, or even between coalition networks.

The above diagram shows a possible CDS configuration using type enforcement. It allows for logging and monitoring and simply passes those messages back through the filters to get them to the high side. In this configuration no single part of the pipeline is trusted to violate the policy, and filters can never be bypassed. This policy would be impossible to enforce with BLP.

Don’t take this to mean that I hate MLS and never think it’s useful. I’m not saying it kicks puppies (although it does occasional pee on rugs I’m told). MLS has a time and a place, just like everything else. The point I’m trying to make is that it shouldn’t be used if it isn’t appropriate, as has been done in the past (and continues to be done today).

During my tenure at Gentoo, running the Hardened Gentoo project, the most common question by far was “How do I secure my system?” Warning, this article may contain some flamebait, avoid it if you can’t resist flaming back .

Eventually we gave up and just pointed people to websites, perhaps this post can serve as that page. The answer was “What do you mean ’secure’ your system?” Security isn’t, and can’t be, a goal by itself. You need to know what exactly you are trying to protect yourself against, your threat model, as it were.

SELinux has the ability to protect against many different threat models. In Hardened Gentoo we also had some complimentary projects that protected against things that SELinux couldn’t, such as PaX (kernel level memory execution protection and memory layout randomization) and SSP (userspace level stack smashing protection). Fedora also has comparable technologies such as Exec Shield baked in by default.

So I saw a thread recently that said something to the concern of “Why use SELinux, which is security bolted onto Linux when you can use OpenBSD which has security as part of the development process?” It’s an interesting question I suppose, if you can decode it. The OpenBSD mantra seems to be develop software correctly in the first place and you don’t need additional layers of security. The baffling part is that you’ll rarely find an OpenBSD user that actually knows what security OpenBSD actually, tangibly provides.

All that said, there are different kinds of security that you might want to implement, and lots of different solutions to attain them.

System Integrity

System integrity is what most people mean when they say “secure my system”. Do you want system integrity? The answer is almost always yes. Some people want very good system integrity and end up using a read only medium, like a livecd or dvd, to run their systems. This, of course, only works if you aren’t storing important data on those systems, for things like web front ends to applications servers it might work fine.

System integrity is what OpenBSD users mean when they say they have a secure system. They integrate quality control into their development process to ensure that as few bugs as possible get into their code and the result is suppose to be high system integrity.

Quality control alone doesn’t give you complete system integrity, however. Your kernel can be well coded but that doesn’t mean much if other processes running as root are vulnerable. Just take a look at ps and see how many applications are running as root. If any of those services are vulnerable your system may have less integrity than previously thought. The fact is everyone runs third party apps on their UNIX/Linux systems. Most users run Apache, samba, syslog, etc and all have components running as root. Even OpenBSD isn’t without vulnerabilities, quality control only goes so far, after that more is necessary.

Memory protection techniques can help protect against some of these vulnerabilities. NX support on modern processors prevent some exploits that use bugs to add shellcode to running applications but that won’t prevent someone from using code already present in the address space, such as system(). Memory layout randomization only provides stop gap protection since the layout can eventually be brute forced, if the administrator isn’t watching very closely.

Mandatory access control is a way of addressing the gaps between a well coded kernel and vulnerable third party applications. If Apache shouldn’t be able to write to anything in /usr then MAC can prevent that. This, by itself, is a huge win for system integrity since it is generally thought that /usr is the highest integrity part of the system.

Now for some explanation. On most systems you can think of integrity as either low or high. High integrity files are files that are system objects. Things in /usr are pretty much all system objects. If a system object gets changed the behavior of the system is changed. A rootkit is going to target these high integrity files, for example. Other examples of high integrity objects are, ofcourse, anything in /boot, /lib, /sbin, /bin, most files in /etc, and so on. User files, on the other hand, are generally low integrity files. Anything in /home is untrusted. User data should never be able to affect the integrity of the system.

The integrity of a process is determined simply by where it gets its input. If a process reads user data, or data off of an untrusted network it is considered low integrity. Apache, which reads /home/*/public_html and receives queries from the internet, is low integrity. RPM, which is run by the administrator, reads rpm’s downloaded from your vendor (hopefully) and installs files all over the system, is high integrity (this is an assessment of how it operates, not whether it is free of vulnerabilities).

Now that you know how to determine the integrity level of objects and processes lets talk about the security policy to maintain system integrity. Biba is a hierarchical integrity policy, similar to Bell LaPadula but, interestingly, the exact opposite. It allows processes to both read and write to objects of the same integrity, no surprises there. Next it allows high integrity processes to write to low integrity objects, but not read them and last it allows low integrity processes to read high integrity objects but not write them.

Though the use of Biba is very limited and has never hit a mainstream operating system it is a very good practice, if implemented in a usable way. The standard SELinux policies implement something between Biba and ‘least privilege’, with a nice balance to ensure system integrity without making the system completely unusable. Biba, for example, isn’t very flexible. Since processes and objects are simply labeled with their integrity there is no way to make practical changes to the policy. You either fall within the constraints of Biba or you are entirely MAC exempt.

The SELinux Apache policy doesn’t allow Apache to write to the high integrity files we talked about above (/usr, /lib, /bin, etc) while allowing it to write to its logs, its cache, etc. Since objects in SELinux have fine grained labeling we can restrict access to apache high integrity objects, such as apache modules, the apache configuration and so on. In many ways SELinux lets us constrain applications more than Biba while at the same time making practical exceptions when necessary. This brings me to my next kind of security.

Application and Data Integrity

While system integrity is generally of the utmost importance, since it is the basis on which you can build other security goals, in some cases it is not enough. Sometimes the most important part of a system is the applications it is running, or the data those applications manage.

For example, if you are running a database server the most important part of the system quite possibly could be the data in that database. How do you protect that data?

We can go back to the mantra of well coded systems with quality control but that, once again, fails when you consider other applications running on the system. Granted you’ll need to trust the database server itself with the data, there is no way around that but the other applications that can access the data can be problematic. Generally database files would be owned by a non-root user with the correct permissions set to prevent other applications from accessing them without going through the database server. Of course root applications can bypass all those restrictions.

There are multiple ways to protect the data. One way is run only the database server on the system and nothing else. That way there is nothing else to protect the data from. This can work in well controlled environments but there are always going to be apps running, like the system logger and sometimes, particularly on UNIX like systems, there is a tendency to put multiple applications on a single system. There will always be the need for backup apps, log monitors, log rotators, etc. This may be a risk you are willing to take, and that is what threat modeling is all about. If you can accept the risk then your security may already meet your needs.

Another way people have tried recently is with hypervisors. Unfortunately the current generation of hypervisors always require a domain 0 or host OS that essentially has full access to the disk, the network interfaces, sometimes the memory, etc. Protecting the integrity of applications within a VM is impossible without first doing so on the host OS, as I pointed out in my Blu-ray post.

MAC systems are IMHO a superior way to handle application and data integrity. SELinux policies can prevent anyone from accessing the database files aside from the database server itself. You may need the backup service to read the database files directly (unless it is configured to get backups directly from the database server itself) but you can easily make the backup server only able to read files without being able to write them, which is not something you can easily do without MAC.

Pipelines

Another security goal which is often overlooked outside of a small niche of guard architects are pipelines. Guards are systems with specific purposes to transfer data from one side to another, while going through a specific set of applications. In the real world one can envision a proxy server or a virus scanning email server as a guard. The idea is that data coming into a system must go through some number of applications before it is allowed to proceed.

In this security goal it is desired that any incoming email goes through a virus and spam filter before going on to the user mail directory and ultimately onto the end users system. This may be more of a functional goal than a security goal to some. As a former administrator I understand the security ramifications of unfiltered email getting through to the network. This kind of goal is generally enforced with configuration of the mail system but for some people that is not enough.

Pipelines obviously rely on system integrity to protect the layer below the pipeline itself, so those security goals are composed onto one another. An opensource project that my company developed called CDS Framework implements this sort of security goal.

Conclusion

There are other security goals one can implement, these are only examples. The first two are probably the most important for most users. The main thing I want people who read this to take away is that there is no such thing as a ’secure system’ or ‘added on security’ or ‘baked in security’. Security by itself doesn’t mean anything. Users need to determine their threat model and security goals in order to determine what measures need to be taken in order to protect what they want protected.

Disclaimer: I am an HDDVD owner but this post is not a result of bitterness about my chosen format losing. The reason I’m posting here about (among others) is the actual reason I chose HDDVD. I also don’t want to talk about the pro’s and con’s of DRM or whether the DRM has been cracked and is accessible via other means. I am going to talk about the intentions of the format producers and what it means to consumers.

So, basically the big security problem I have with Blu-Ray is that BD+ (a BluRay specific DRM mechanism) has some scary provisions to make movie producers happy. Basically the idea behind BD+ is that the movie, decoding, etc is done from within a virtual machine.

So the problem with using a virtual machine to protect the data from the person who owns the device is that the host inherently can access and manipulate the virtual machine itself, including the data. This presents a fundamental problem with the idea of protecting the content. So in order to address this the movie producer must be satisfied that the host machine is in a state where the virtual machine is considered safe.

This is where BD+ gets scary. It allows movie producers to package arbitrary host executables with the BD+ virtual machine that is run on the player before the virtual machine unencrypts any content. The idea, of course, is that a vulnerable host (that is, a host that allows unauthorized access to the unencrypted content) can be patched in order to close the vulnerability. This has some serious ramifications including, but not limited to, producers being able to rootkit machines (see sony’s recent rootkit fiascos), spyware, broken patches that make systems more vulnerable, broken patches that break machines, patches that affect different OS releases differently, etc.

I almost wish a producer would create a PS3 patch that bricks a bunch of PS3’s just to show how very very dangerous “features” like this are.

So that is one of the features that scared me the most. There are other problems I had that caused me to choose HDDVD such as incomplete specifications for BluRay, fewer features in the original specifications, limits on the layering of the disks and so on. I now have a dilemma about whether to get a BluRay player knowing that, as a consumer, the choices I make validate the behavior of the producers. The most disturbing fact is that the consumers who don’t know about these issues have implicitly allowed the format producers and movie producers to build this incredibly anti-consumer system. C’est la vie I suppose.

inode-based security has analogous problems to path-based security. Software opens paths, not inodes, so it very much matters what the permissions are for the file at /etc/shadow or /var/data/mydb, regardless of what the inode happens to be. With an inode-based system, security may go out the window when programs replace or manipulate inodes, as many of them do.

Software opens paths because paths are the exposed abstraction for userspace applications. Sure it matters what permissions are on /etc/shadow, but those permissions and the access control alike is always done at the inode level, as I will demonstrate below. Applications that manipulate inodes have always needed to set security attributes on those inodes, look at passwd source code and you will see that it creates the inode with mode 400 (r——–).

So, neither AppArmor nor SELinux provide bullet proof security or data integrity, although both may be useful in protecting against some problems.

This is blatantly wrong, SELinux provides controls to specify precisely how things can be labeled. If my policy does not allow an application that handles confidential information to relabel or create a file with a label that is accessible by other applications there are no circumstances where that application will be able to leak the data. Similarly if an application can’t read low-integrity data and write to high-integrity files there are no circumstances where the application can harm the data integrity. I suggest you read some of the papers about SELinux policy analysis and information flow to understand the issues and how SELinux can address them. Many are available at the SELinux symposium website.

But arguments like the ones in this blog really make me doubt whether the SELinux people even understand the issues or have much of a notion of how files and security work on real-world UNIX systems.

As much as I’d like to ignore people using ad hominum attacks there may be others under this impression. Note the following demonstration as a counter example:

# ls -al /etc/shadow
-r-------- 1 root root 947 2007-06-06 03:40 /etc/shadow

# ln /etc/shadow /tmp/shadow
# ls -al /tmp/shadow
-r-------- 2 root root 947 2007-06-06 03:40 /tmp/shadow

# chmod 777 /tmp/shadow
# ls -al /etc/shadow
-rwxrwxrwx 2 root root 947 2007-06-06 03:40 /etc/shadow

It should be clear at this point that the UNIX permissions absolutely do not have anything to do with paths, only with inodes. This is how real-world UNIX systems have always worked, path based mechanisms break that convention and are subject to the issues I’ve noted in the path based article. The simple fact is that UNIX systems never ever use paths to determine access to anything, access control has always been centered around inodes and permissions set on inodes. Do not think that the existance of paths changes that, these are merely an abstraction to make userspace more useful.

The arguments against SELinux by the AppArmor people, and others, are purely functionality based arguments. They want to use paths because paths are easy to understand and paths have conventions that can be reflected in their policy (eg., that passwords are always stored in /etc/shadow and therefore that file should be protected). SELinux provides mechanisms to enforce many different security policies including protecting /etc/shadow and /var/data/mydb.