Wandering Thoughts archives


The problem with SELinux (still)

Here's a list of almost all of the bugs that got fixed in recent Fedora 17 SELinux policy update:

867107 - SELinux is preventing /usr/sbin/in.tftpd from using the 'dac_override' capabilities.
868656 - SELinux is preventing /usr/bin/python2.7 from using the 'sys_nice' capabilities.
868866 - SELinux is preventing /usr/sbin/fping from 'create' accesses on the rawip_socket .
869468 - SELinux is preventing tuned from using the 'setsched' accesses on a process.
871097 - SELinux is preventing haveged from 'read' accesses on the file meminfo.
872768 - SELinux is preventing /usr/sbin/rpc.statd from 'write' accesses on the sock_file rpcbind.sock.
872894 - SELinux is preventing /usr/libexec/nm-openvpn-service from 'open' accesses on the file /home/karl/.cert/klatiss.key.
873030 - SELinux is preventing /usr/bin/dbus-daemon from 'write' accesses on the blk_file /dev/sdb.
873393 - SELinux is preventing /usr/bin/qemu-system-x86_64 from using the 'execmem' accesses on a process.
846001 - type=AVC msg=audit(1344196154.847:445): avc: denied { create } for pid=6975 comm="rhnsd" scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:system_r:rhsmcertd_t:s0 tclass=unix_dgram_socket
868456 - SELinux is preventing freshclam from search access on the directory amavisd.
870659 - SELinux is preventing agetty from access on ttyUSB0.
821189 - SELinux is preventing polkit-agent-he from using the 'setsched' accesses on a process.
860226 - SELinux is preventing /usr/sbin/nslcd from 'name_connect' accesses on the tcp_socket .
865328 - SELinux is preventing /usr/lib64/nspluginwrapper/npconfig from 'getattr' accesses on the filesystem /.

I want to emphasize that this is a completely typical bug list for a completely typical SELinux policy update. I have not cherry-picked an unusually long one; they are pretty much all like this.

Fedora has been using SELinux for years, probably at least half a decade by now. It is still fixing many, many instances where SELinux gets in the way of programs doing legitimate things that people want them to do. The progress that it has made in literally years is at best that these are somewhat more obscure programs doing somewhat more unusual things than they used to be. Using SELinux in non-mainstream environments still means a steady rain of these denials, all of them getting in your way.

(Distributions have spent years desperately trying to make it easier to deal with this rain, but it is still a pain in the rear. I run into it periodically on my laptop, which I still masochistically have SELinux turned on on.)

Note that this is not using SELinux in non-default configurations. These bugs are all (I assume) from stock configuration systems that SELinux just didn't quite cope with correctly.

At a meta-level all of these bugs happen because doing a complete inventory of legitimate program behavior is very hard, especially because it's not something that can be done automatically (at least currently). A fallible human has to stare a lot at a program to write its SELinux policy, and if they miss something you get another one of these bugs. People miss obscure corner cases a lot, especially when they are not intimately familiar with all of the aspects of the software.

Also, these are only the bug fixes for the bugs that people actually reported to Fedora. Since reporting Fedora bugs involves more than a little bit of work and pain I assume that any number of people don't bother to report SELinux problems that they run across; they either just tell the system to make things work or they turn SELinux off entirely.

(See also.)

linux/SELinuxStillProblems written at 17:17:09; Add Comment

A potential path to IPv6

For reasons beyond the scope of this entry, I wound up thinking about thinking about the (potential) transition to IPv6 again today. In the past I've been solidly gloomy on the prospects for a transition to IPv6, in large part because IPv6 doesn't benefit the people who have to do the work; the people who benefit from a transition are the people who don't already have IPv4 addresses, not the people who do. But today a potential path out of this occurred to me.

First off, let's assume that people start running out of assignable IPv4 addresses, as seems quite likely. When this happens, what we'll probably start seeing (and what has apparently started in some places) is consumer IPv6-only deployments that talk to the IPv4 world through large 'carrier grade' NAT systems. This only really allows outgoing connections (at least for IPv4 stuff), but for many ISPs that's a feature; if you want to run a server you can pay them for the privilege.

(If all of the software works fine most consumers won't care or notice.)

Of course even carrier grade NAT is not perfect or completely transparent. This is likely to result in an experience that's worse than directly accessing the same web site or other resource over native IPv6. With a worse experience for IPv4 than IPv6, if you want to do a good job serving these consumers you have an incentive (possibly a big one) to provide native IPv6 connectivity for your own services.

In other words, now you have a positive economic incentive to add native IPv6 support to your systems. Positive economic incentives (aka 'making more money') make the world go around, because they give organizations a concrete reward for the work they do.

(I will note in passing that the consumer ISPs involved have their own economic incentive to encourage IPv6 connectivity; the more native IPv6 their customers do, the less they need those expensive carrier grade NAT boxes.)

Where are these consumers? I think they're likely to be in what we today consider somewhat the peripheries of Internet usage, the places where it is only a recent development. North America generally has plenty of IPv4 addresses for its population, while places like Asia, Africa, and the Middle East are probably under-supplied. If this path to IPv6 is accurate, I'd expect to see serious IPv6 usage first show up in companies that are targeting these 'peripheral' users. And I wouldn't expect these companies to be based in North America.

(In fact I wouldn't be surprised if North America and western Europe wind up lagging the rest of the world in any IPv6 transition. The bigger question is if that will matter much.)

(All of this was in part sparked by (re)reading Avery Pennarun's entry on IPv6 from early 2011, due to reading this more recent entry of his.)

tech/PathToIPv6 written at 01:43:45; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.