Slides from all of the talks at Netconf 2006, and photos, are being made available at
http://vger.kernel.org/netconf2006.html (bottom of the page).
It’s been a great summit again, and it’s very sad to be leaving Tokyo. Thanks to all of the sponsors, and especially Yoshifuji-san of USAGI.
DaveM made a new friend at the University of Tokyo:
Uploaded a photo set from the conf: click here.
Here are the slides from my Netconf 2006 talks.
- Better IPsec SA Resolution (PDF)
Some discussion of the case where we need to send a packet, but have no IPsec security association for it. Generally, we currently return EAGAIN to applications and initiate an SA negotiation, but this seems less than optimal. One approach is to not return an error (which some implementations do) so that applications don’t die from surprise. We could also queue the packet and wait for the negotiation to complete, with appropriate semantics for various scenarios.
The big question at this point is: in what situations are people seeing this? Generally, the key manager will maintain SAs as needed, and the case of not having one established is believed to be unusual, but we don’t really know for sure. Opportunistic encryption would likely benefit from proper queuing, but it’s not clear how widely it’s deployed.
- OLPC Networking Overview (PDF)
Brain dump of what I understand currently of the networking aspects of the OLPC project, which I thought might be of interest to other kernel network developers.
- Mandatory Access Control Networking Update (PDF)
Coverage of developments in MAC networking over the last year, including the new Secmark controls & SELinux, completion of the native xfrm IPsec labeling to meet LSPP/EAL4 , and CIPSO support. Paul Moore from HP will be giving a more detailed talk on CIPSO today or tomorrow.
Also, met up with some local SELinux developers at lunch time: Kaigai Kohei , Kazuki Omo and Yuichi Nakamura. After noticing a six-page SELinux article in a Japanese Linux magazine last night while shopping in Akihabara Electric Town, I asked them if they’d seen it and it turns out that Nakamura-san wrote it, and that he writes a monthly SELinux column for the magazine. We had some discussion about SELinux usability, SE postgresql and JFFS2 support. Unfortunately, we ran out of time — hopefully we’ll get to talk again at the next SELinux symposium.
(Which reminds me to note that the CFP submissions are due on October 9th).
I wonder how many people know that there’s an official Netfilter Song.
I’m in Tokyo for Netconf 2006.
Harald Welte told me at breakfast that Motorola A1200 phones run SELinux, and that a million of these have been sold in China. It’d be interesting to see their security policy.
The A1200 is not running real SELinux, it’s a derived LSM called “Motorola Access Control”. The source is available here:
Wade Mealing blogged Do the Fedora Developers run with SELinux enabled ?, after encountering a lot of AVC messages on his Fedora Core box. Looking at the messages, it seems that the system is out of whack generally and needs to be relabeled. The cleanest way to do this is:
# yum update
# touch /.autorelabel
and the early init scripts should fix the labels.
The hint that it’s a general labeling problem is the presence of file_t and unlabeled_t labels in the AVCs, which are generic fallback values and should not typically be seen in the wild. In fact, any AVC messages or SELinux issues for a normal user should be regarded as a bug.
This type of thing should not normally ever happen and we’d really like to know how the system got into this state. It could be that the policy has not been kept up to date with the rest of the system, which should only really be an issue for people who are playing with development versions of the distro and selectively upgrading rpms. It’s also possible that the presence of hard disk error messages in the logs has something to do with it. Another possible cause is mounting a non-labeled disk somewhere critical in the fs. Without more detailed information, we don’t know for sure, so please always report bugs.
Any of the following mailing lists are good for this:
- http://www.redhat.com/mailman/listinfo/fedora-selinux-list (subscriber-only)
SELinux-related bugzilla entries are typically resolved very quickly:
Bugs are good.
Send us some!
Note that soon, setroubleshoot will have a plugin for this specific issue, and explain to the user what’s wrong and what to do about it.