Chris's Wiki :: blog/linux/SELinuxWhatNext Commentshttps://utcc.utoronto.ca/~cks/space/blog/linux/SELinuxWhatNext?atomcommentsDWiki2013-06-10T19:19:24ZRecent comments in Chris's Wiki :: blog/linux/SELinuxWhatNext.From 82.197.216.4 on /blog/linux/SELinuxWhatNexttag:CSpace:blog/linux/SELinuxWhatNext:c76fa5be342a2bfdea5e9e90a23cbc24b6dcd9ecFrom 82.197.216.4<div class="wikitext"><p>"There is nothing like that for SELinux. Many software packages can get away with "disable SELinux" as the first install step. Even RedHat does not show a commitment to SELinux. RedHat could force packages to come with SELinux configurations out of the box."</p>
<p>You must be joking..</p>
<p>1. Red Hat shows leadership by enabling SELinux by default
2. Red Hat has SELinux security built into libvirt, openshift and other major technologies
3. Red Hat has people working full time on SELinux
4. Red Hat includes SELinux in their training courses and certification
5. Many operating system components have extensions to SELinux (dbus, xserver, systemd, and others)</p>
<p>It seems that it is really hard to grasp the concept of computer system security and mandatory access control.</p>
<p>The idea of MAC is that policy is governed centrally, and in many cases is transparent to the application layer. You cannot trust packagers ( or anyone for that matter ) to make security decisions for you.</p>
<p>What does a run of the mill application coder know about security? About your environment?, your requirements?</p>
</div>2013-06-10T19:19:24ZFrom 128.101.135.18 on /blog/linux/SELinuxWhatNexttag:CSpace:blog/linux/SELinuxWhatNext:78ce55da5a83d7b3b58eb85eeab10b152b71b9c5From 128.101.135.18<div class="wikitext"><blockquote><blockquote><p>Nobody had this much heartburn when firewalls were put in and they had the same issues including silently blocking stuff/dropping packets. But user education WAS the key in that case and everyone learned to live with them. It's the same thing. Block everything, allow only what is necessary. Learn the tools.</p>
</blockquote>
</blockquote>
<blockquote><p>Really? I run into this 2-3 times a week for our network firewalls. Admins here live with them because they don't have a choice, but there's a certain number of them who, if given the choice, would happily enable from any to any, any application, and carry on.</p>
</blockquote>
<blockquote><p>MP</p>
</blockquote>
<p>SELinux != Firewall. </p>
<p>Bigger shops have a person, or handful of people that manage the border firewall. Software packagers have also been forced to include directions for making a hole for the software through the firewall.</p>
<p>There is nothing like that for SELinux. Many software packages can get away with "disable SELinux" as the first install step. Even RedHat does not show a commitment to SELinux. RedHat could force packages to come with SELinux configurations out of the box.</p>
</div>2013-06-10T18:39:35ZFrom 129.97.109.15 on /blog/linux/SELinuxWhatNexttag:CSpace:blog/linux/SELinuxWhatNext:55f8727fb1983279f19ab5cd125490fac53243c5From 129.97.109.15<div class="wikitext"><blockquote><p>Nobody had this much heartburn when firewalls were put in and they had the same issues including silently blocking stuff/dropping packets. But user education WAS the key in that case and everyone learned to live with them. It's the same thing. Block everything, allow only what is necessary. Learn the tools.</p>
</blockquote>
<p>Really? I run into this 2-3 times a week for our network firewalls. Admins here live with them because they don't have a choice, but there's a certain number of them who, if given the choice, would happily enable from any to any, any application, and carry on.</p>
<p>MP</p>
</div>2013-06-10T15:32:20ZBy Chris Siebenmann on /blog/linux/SELinuxWhatNexttag:CSpace:blog/linux/SELinuxWhatNext:4405cc57d493ca9ed8cc70a10f3ed36b04edd6a5Chris Siebenmann<div class="wikitext"><p>dsr: I think that what you note is endemic to anything that humans do,
not just software. My guess is that it is in part a variant of the sunk
cost fallacy.</p>
</div>2013-06-10T15:12:41ZFrom 207.172.69.99 on /blog/linux/SELinuxWhatNexttag:CSpace:blog/linux/SELinuxWhatNext:cd11f91edd9e3ca86cb025d8a4490ac96d43e916From 207.172.69.99<div class="wikitext"><p>This sounds remarkably like the problems of GNOME 3 and the Debian systemd folks.</p>
<p>In both cases, the immediate response to any suggestion that people aren't happy with their software is to ask for a list of problems, admit to the most minor issue, and then deny that anything else is a real issue: people just don't know enough, haven't tried it, and haven't read the docs.</p>
<p>So if there are three situations like this, there are probably more.</p>
<p>Is it endemic to open source projects? Or perhaps to software projects in general?</p>
<p>-dsr-</p>
</div>2013-06-10T13:16:52ZFrom 194.176.241.90 on /blog/linux/SELinuxWhatNexttag:CSpace:blog/linux/SELinuxWhatNext:7d767f68c268188fe851fe12ea4b8d22547c5d50From 194.176.241.90<div class="wikitext"><p>The "Managing Confined Services" document is really good - however it has zero information about syslog/rsyslog. :-(</p>
<p>I know that as SElinux is evolving its documentation is evolving as well and I think it will be really-really good in a few years - however the current state is still a bit sloppy :/</p>
</div>2013-06-10T13:15:31ZFrom 82.197.216.4 on /blog/linux/SELinuxWhatNexttag:CSpace:blog/linux/SELinuxWhatNext:e968d4badf4ddc1f96df5225b17f84ed0e3fea53From 82.197.216.4<div class="wikitext"><p>Let me just expand a little on my previous comment:</p>
<p>Compare SELinux to network firewalls:</p>
<p>1. Netfilter in the Linux Kernel < -- > SELinux in the Linux Kernel
2. iptables utilities and libraries < -- > SELinux utilities and libraries
3. iptables configuration < -- > SELinux policy configuration</p>
<p>People often judge SELinux on its stock configuration. Just like some might judge netfilter on a the stock iptables ruleset.</p>
<p>That is not fair.</p>
<p>The rules/policy are just configuration, and it should be obvious that there is not one-size-fits-all iptables configuration or SELinux policy configuration.</p>
<p>Because each environment has its on properties and requirements.</p>
<p>Default rule sets are shipped so that at least some level of protection can be provided out of the box, but a responsible system administrator is expected to adjust the rules/policy to the environments properties and requirements.</p>
<p>netfilter and selinux framework gives us the attributes we need to solve our specific network and system challenges.</p>
<p>People tend to judge SELinux on how it is configured, but SELinux is so much more.</p>
<p>SELinux enables one to address challenges in a wide array of scenarios because it is flexible and configurable, but the keyword here is <em>enables</em>, and only you can identify threats to your environment, properties of your environment and your requirements.</p>
</div>2013-06-10T12:46:07ZBy Chris Siebenmann on /blog/linux/SELinuxWhatNexttag:CSpace:blog/linux/SELinuxWhatNext:88cdaf413ec5c5d05de36513c5fac3505054cad2Chris Siebenmann<div class="wikitext"><p>I mean 'real problems' here in a more general sense than I think you
are taking it. Firewalls are actually a great example because the
introduction of firewalls solved several general problems that people
were having, such as 'we have insecure internal machines that keep
getting attacked from the Internet'.</p>
<p>(One mark of solving a real problem, one that people are actually
having, is that you can tell lots of stories about real, actual bad
stuff that your solution prevented. I do not think that SELinux can
do that today; as I've said before, <a href="https://utcc.utoronto.ca/~cks/space/blog/linux/SELinuxIsABackup">today SELinux is a backup</a>.)</p>
<p>'Least privilege' is a technical detail. People do not care about
technical details; they care about having their problems solved. If you
do not solve their problems and you cause them problems, you will get
thrown out. If SELinux focuses on technical details instead of solving
problems that people are having, it will continue to fail in any number
of situations and the SELinux community can look forward to years of
sysadmins telling each other 'oh, SELinux, ha, almost everyone disables
that first thing'.</p>
<p>(See <a href="https://utcc.utoronto.ca/~cks/space/blog/tech/SocialProblemsMatter">social problems are the real problems</a> and <a href="https://utcc.utoronto.ca/~cks/space/blog/tech/SecurityIsPeople">computer security is people</a> for more on this general issue. I keep
banging on this drum because it is very important for actually getting
security.)</p>
</div>2013-06-10T12:39:42ZFrom 46.144.78.131 on /blog/linux/SELinuxWhatNexttag:CSpace:blog/linux/SELinuxWhatNext:9fae224f242cbfdc04e0649a7437d3b09ed0a053From 46.144.78.131<div class="wikitext"><p>the documentation is right where you would expect it to be:</p>
<p>general doc site for RHEL:
<a href="https://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/?locale=en-US">https://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/?locale=en-US</a> </p>
<p>Inside that page, search selinux:
<a href="https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/index.html">https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/index.html</a></p>
<p>Also nice howto run confined services:
<a href="https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Confined_Services/index.html">https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Confined_Services/index.html</a></p>
<p>Not so hard to find I think ;-)</p>
<p>As to the real problems it should be addressing, if you do not know them by now, just disable the stuff.</p>
</div>2013-06-10T12:23:23ZFrom 82.197.216.4 on /blog/linux/SELinuxWhatNexttag:CSpace:blog/linux/SELinuxWhatNext:285351c53bddd18cdc61ab0927d2e94060a9e08cFrom 82.197.216.4<div class="wikitext"><p>""Put another way, SELinux needs to solve real problems and by 'real problems' I mean problems that are actually affecting people in the real world (not theoretical possibilities of threat models)."</p>
<p>This is just a whole lot of FAIL."</p>
<p>Totally agree. SELinux does not solve problems. SELinux <em>enables</em> one to solve problems.</p>
<p>SELinux is a Flexible MAC security <em>framework</em></p>
</div>2013-06-10T12:22:31ZFrom 216.105.40.123 on /blog/linux/SELinuxWhatNexttag:CSpace:blog/linux/SELinuxWhatNext:a909a1b2696bdba66717203aeddfa10455ae573dFrom 216.105.40.123<div class="wikitext"><p>"Put another way, SELinux needs to solve real problems and by 'real problems' I mean problems that are actually affecting people in the real world (not theoretical possibilities of threat models)."</p>
<p>This is just a whole lot of FAIL.</p>
<p>You are basically asking the SELinux community to accurately predict the future exploits and only put in the bits of least privilege that will stop those particular exploits. This is Ranum's "enumerating badness".</p>
<p>Nobody had this much heartburn when firewalls were put in and they had the same issues including silently blocking stuff/dropping packets. But user education WAS the key in that case and everyone learned to live with them. It's the same thing. Block everything, allow only what is necessary. Learn the tools.</p>
</div>2013-06-10T10:24:14ZFrom 194.176.241.90 on /blog/linux/SELinuxWhatNexttag:CSpace:blog/linux/SELinuxWhatNext:c6dde4cfea79c60c89d6585fe4b56a5f486a9c26From 194.176.241.90<div class="wikitext"><p>I would like to use SElinux in certan situations, e.g. a few months ago I migrated a company's logging system to use TCP/TLS transport, replacing their old UDP/plain transport. The benefit was to comply some government regulation.</p>
<p>Dealing with SElinux was difficult because I couldn't easily find answers to questions like:</p>
<p>- How SElinux affects logging in general? What details do I need to pay attention to?</p>
<p>- Where can I find the documentation? I know there are labels, booleans and and a ruleset surrounding logging and SElinux, but where are all these stuff documented? I know there are supposed to be man pages about these but what exact man pages should I read? How can I find out the names of the man pages?</p>
<p>Later in the project, after asking questions around the web I reached the phase where I had to deal with best-practice questions, like:</p>
<p>- Which is the better way to deal with custom application logs, creating a new label and allowing syslog processes access to it or simply labeling custom logs as log_t?</p>
<p>I have to say it was definitely difficult to find answers to these questions. It is possible, but it takes a lot of time. And I can imagine, if I need to build an apache web server farm the next time, I have to go through this painful procedure again :-(</p>
<p>My suggestion to the SElinux guys is to provide meaningful documentation about their software. I know they are improving, but there is still a lot of room to reach general usability.</p>
</div>2013-06-10T08:24:34Z