What are the main impacts of SELinux, from an administration point of view?

Actually, if you run a modern distribution of Linux, such as Fedora or CentOS, chances are good that you already have "an SELinux system".

Think of it like this analogy: imagine a society whose system of government is "anarchy". Anyone can do anything. Individual tribes can establish localized areas of control, basic levels of order, but on the whole, at the regional or global level, the civilization is in anarchy, and the person or people who have the most sheer influence or power (physical strength, technology, etc) can pretty much do what they want without any repercussions.

This is what a system is like when SELinux is not installed, or installed but not enforcing.

Now imagine a society whose system of government involves the "Rule of Law", which is a concept meaning that, rather than people ultimately ruling society, a formal set of rules written in a book rules society.

This is what a system is like when SELinux is installed and enforcing.

Now, granted, it is possible to enable SELinux, set it to enforcing, and clear out the book of law, and either have a blank book, or write "You're allowed to do absolutely anything you want" -- which brings us back to anarchy. Sort of. But if the book of law suddenly changes so that it contains some actual restrictions, like, murder is illegal, stealing is illegal, etc., then suddenly society can begin to have some degree of order. And it won't be possible in general for people with lots of power to simply use that to do anything they want, because laws can restrict what they're allowed to do.

For the purposes of the analogy, we'll pretend that people never do things that are illegal, because in the software world, a program can't bypass a SELinux policy (a.k.a. "break the law") just because it really wants to. In regular human society, we can of course break the law, and then there are consequences for that. In SELinux society, you just don't break the law, ever, period.

As you can imagine, the amount of administrative overhead in a SELinux system depends heavily on:

• how many policies you have enabled;
• how restrictive those policies are;
• how specific those policies are;
• whether you have policies set up that are blacklists or whitelists (blacklists block out things that you know are bad, while whitelists require you to explicitly add support for things that you want to allow, because everything is blocked by default).

SELinux can restrict almost any aspect of the system that is controllable from within the Linux kernel: access to hardware devices, access to read or write files, access to system APIs, access to certain types of networking or certain scopes of networking, and so on. SELinux effectively implements Mandatory Access Control, which you should continue reading about on Wikipedia.

The important point I wanted to instill in you with this answer is that the amount of extra work and time spent dealing with SELinux depends entirely on how restrictive you make the policies. For instance, imagine living in a society where you have to gain approval from four people every time you want to board an airplane: a Justice of the Supreme Court, the President, a member of the House of Representatives, and a Senator. This would be an extremely restrictive policy, and you'd have to go through a lot of approvals to get on a plane. In the SELinux world, this would be akin to blacklisting all filesystem access by default, and requiring explicit whitelisting of individual users' access to individual files.

Remember I said earlier that Fedora and CentOS already implement SELinux? You probably don't even notice that they do, unless you download and run specific programs that attempt to do things that trip a SELinux filter. Red Hat has carefully tuned their SELinux filters over time to allow almost all non-malicious program activity to pass through unhindered, but it has a few policies in place that should help deter attacks, without being too burdensome on the system administrator.

In short, SELinux, in the way it is implemented out of the box on Red Hat based distros, enhances security without significantly impacting usability. You can, of course, make it even more secure from there, but it would also reduce usability in turn; or, you could make it even more usable, but it would also reduce security in turn.