Planet SELinux

Shintaro Fujiwara: segatex-6.70 ??

2008-08-27T11:50:33+00:00

I should fix sub program, segatex alert audit, which is a independent c program should pop up alert notice when violation occurs.
I wrote this one hoping to be like setroubleshoot.
But in fact, I have scarce knowledge on kernel which I found file-oriented alert program.
In a sense it's OK, but when it comes to the real world, it is not working well.
I make it pops up every several seconds or minutes when some file stamp which I created differs from former one.

So, I should re-write this totally to co-ordinate with kernel thing and alert properly.

Maybe I should ask kernel masters like Mr. J.M. or other people I respect.

Thanks to the help from them, I evolved from several years ago and now I can write c++ program allright, so maybe I will be happy to contribute more to the security world.

My job is security itself, you know that...

Dan Walsh: Top three things to understand in fixing SELinux problems.

dwalsh@redhat.com — 2008-08-26T16:25:14+00:00

Almost all SELInux problems fall into one of the following three categories. While this might be an over simplification, I think it is a good thing for a new user to understand.

1. SELinux is all about labeling
Every process and object on the machine has a label associated with it, if your files are not labeled correctly access might be denied.

If a file is mislabeled a confined application might not be allowed access to the mislabeled file. If an executable is mislabeled, it may not transition to the correct label when executing, causing access violations and potentially causing it to mislabel files it creates. Processes and objects on the machines have labels. If the labeling is correct everything should work. Sometimes an admin decides to change the default labeling on the system. If an admin wants to store apache web pages in a unusual location, /srv/myweb. The admin needs to tell SELinux that the files stored there need to be accessible to the web server process. He does this by setting the labeling correctly in the system. The apache process is allowed to access files labeled httpd_sys_content_t.

# semanage fcontext -a -t httpd_sys_content_t '/srv/myweb(/.*)?'

This command tells the SELinux datastore that the /src/myweb directory and all files under it should be labeled httpd_sys_content_t. Tools like restorecon and rpm read this datastore when they are labeling or relabeling files. Note, however that the semanage command will not change the actual labels on files on your machine. You still need to execute restorecon to fix the labels.

# restorecon -R /srv/myweb

restorecon reads the SELinux datastore to determine how files under /srv/myweb should be labeled and then fixes them.

# matchpathcon /srv/myweb

matchpathcon reads the SELinux datastore and prints the default label for the specified path

2. You have to tell SELinux about how a confined process is being run.
A confined process/application can be run in many different ways. You need to tell SELinux about how you are configuring the application to run, so SELinux will allow it the proper access. SELinux does not do this automatically, SELinux has builtin if/then/else rules called booleans that allow you to tweak the predefined rules to allow different access. If you set up you apache web server to talk to a mysql server, you need to set a boolean to tell SELinux this is ok. You can do this with the setsebool command.

# setsebool -P httpd_can_network_connect_db 1

Tools like system-config-selinux or getsebool -a will list all of the possible booleans. On the latest Fedora systems you can run SELinux error messages (avc) through audit2allow -w (audit2why). This checks to see if any boolean could be set to allow the access. setroubleshoot is also pretty good at diagnosing problems.

3. SELinux rules are evolving and applications are sometimes broken

General errors in policy or applications can cause SELInux access denials. Sometimes an application is just broken or the SELinux policy has never seen the confined application run the code path that it is running. While the application is working correctly, SELinux is denying it access. You can add custom policy to your system simply by piping the SELinux error messages through audit2allow. Say a new version of postgresql comes out that SELinux is mistakenly denying access to a resource which it should be allowed to access. You can use audit2allow to build a custom policy module that can be installed on your system to allow the access.

# grep postgresql /var/log/audit/audit.log | audit2allow -R -M mypostgresql

This command will generate a local policy module which will allow all accesses that are currently being denied..

# semodule -i mypostgresql.pp

This command installs the local policy modifications to your system. You probably want to report the SELinux errors to bugzilla or a mailing list so your local modifications can be added to the distribution's policy or upstream.

Yuichi Nakamura: [SELinux]先日のオタワのレポート記事

himainu — 2008-08-26T14:39:30+00:00

公開された。 http://www.atmarkit.co.jp/fsecurity/special/127ottawa/ottawa01.html 金曜はCELFでオタワの様子を紹介予定です。意外とオタワ後のイベントが多いです。 http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree22

Yuichi Nakamura: [SELinux] OpenSuseにSELinux

himainu — 2008-08-25T12:40:16+00:00

http://selinuxnews.org/wp/index.php/2008/08/21/opensuse-111-to-enable-selinux/ SuSEもSELinuxサポートを入れるらしい。 AppArmor、本格的に活動低下なのだろうか。。。。

Yuichi Nakamura: [SELinux] レッドハットやFedora Projectのサーバに不正侵入

himainu — 2008-08-25T12:40:15+00:00

http://www.atmarkit.co.jp/news/200808/25/redhat.html targetedポリシだったら、SSHのアカウント取られてログインされたら、SELinux使ってようと意味無かったりするし。。。

Russell Coker (security): Is SE Linux Unixish?

etbe — 2008-08-25T08:58:27+00:00

In a comment on my AppArmor is dead post [1] someone complained that SE Linux is not “Unixish“.

The security model in Unix is almost exclusively Discretionary Access Control (DAC) [2]. This means that any process that owns a resource can grant access to the resource to other processes without restriction. For example a user can run “chmod 777 ~” and grant every other user on the system the ability to access their files (and take over their account by modifying ~/.login and similar files). I say that it’s almost exclusively DAC because there are some things that a user can not give away, for example they can not permit a program running under a different non-root UID to ptrace their processes. But for file and directory access it’s entirely discretionary.

SE Linux is based around the concept of Mandatory Access Control (MAC) [3]. This means that the system security policy (as defined by the people who developed the distribution and the local sysadmin) can not be overridden by the user. When a daemon is prevented from accessing files in a user’s home directory by the SE Linux policy and the user is not running in the unconfined_t domain there is no possibility of them granting access.

SE Linux has separate measures for protecting integrity and confidentiality. An option is to use MultiLevel Security (MLS) [4], but a more user-friendly option is MCS (Multi-Category Security).

The design of SE Linux is based on the concept of having as much of the security policy as possible being loaded at boot time. The design of the Unix permissions model was based on the concept of using the minimal amount of memory at a time when 1M of RAM was a big machine. An access control policy is comprised of two parts, file labels (which is UID, GID, permissions, and maybe ACLs for Unix access controls and a “security context” for SE Linux) and a policy which determines how those file labels are used. The policy in the Unix system is compiled into the kernel and is essentially impossible to change. The SE Linux policy is loaded at boot time, and the most extreme changes to the policy will at most require a reboot.

The policy language used for SE Linux is based on the concept of deny by default (everything that is not specifically permitted is denied) and access controls apply to all operations. The Unix access control is mostly permissive and many operations (such as seeing more privileged processes in the output of “ps”) can not be denied on a standard Unix system.

So it seems that in many ways SE Linux is not “Unixish”, and it seems to me that any system which makes a Unix system reasonably secure could also be considered to be “not Unixish”. Unix just wasn’t designed for security, not that it is bad by the standards of modern server and desktop OSs.

Of course many of the compromises in the design of Unix (such as having all login sessions recorded in a single /var/run/utmp file and having all user accounts stored in a single /etc/passwd file) impact SE Linux systems. But some of them can be worked around, and others will be fixed eventually.

[1] http://etbe.coker.com.au/2008/08/23/apparmor-is-dead/

[2] http://en.wikipedia.org/wiki/Discretionary_Access_Control

[3] http://en.wikipedia.org/wiki/Mandatory_access_control

[4] http://en.wikipedia.org/wiki/Multilevel_security

Share This

Russell Coker (security): Play Machine Downtime

etbe — 2008-08-23T22:39:22+00:00

From the 13th to the 14th of August my Play Machine [1] was offline. There was a power failure for a few seconds and the machine didn’t boot correctly. As I had a lot of work to do I left it offline for a day before fixing it. The reason it didn’t boot was that due to an issue with the GRUB package it was trying to boot a non-Xen kernel with Xen, this would cause the Xen Dom0 load to abort and it would then reboot after 5 seconds - and automatically repeat the process. The problem is that update-grub in Lenny will generate boot entries for Xen kernels to boot without Xen and for non-Xen kernels to boot with Xen.

Two days ago someone launched a DOS attack on my Play Machine and I’ve only just put it back online. I’ve changed the ulimit settings a bit, that won’t make DOS attacks impossible, just force the attacker to use a little bit more effort.

[1] http://www.coker.com.au/selinux/play.html

Share This

Russell Coker (security): AppArmor is Dead

etbe — 2008-08-23T00:47:53+00:00

For some time there have been two mainstream Mandatory Access Control (MAC) [1] systems for Linux. SE Linux [2] and AppArmor [3].

In late 2007 Novell laid off almost all the developers of AppArmor [4] with the aim of having the community do all the coding. Crispin Cowan (the founder and leader of the AppArmor project) was later hired by Microsoft, which probably killed the chances for ongoing community development [5]. Crispin has an MSDN blog, but with only one post so far (describing UAC) [6], hopefully he will start blogging more prolifically in future.

Now SUSE is including SE Linux support in OpenSUSE 11.1 [7]. They say that they will not ship policies and SE Linux specific tools such as “checkpolicy”, but instead they will be available from “repositories”. Maybe this is some strange SUSE thing, but for most Linux users when something is in a “repository” then it’s shipped as part of the distribution. The SUSE announcement also included the line “This is particularly important for organizations that have already standardized on SELinux, but could not even test-drive SUSE Linux Enterprise before without major work and changes“. The next step will be to make SE Linux the default and AppArmor the one that exists in a repository, and the step after that will be to remove AppArmor.

In a way it’s a pity that AppArmor is going away so quickly. The lack of competition is not good for the market, and homogenity isn’t good for security. But OTOH this means more resources will be available for SE Linux development which will be a good thing.

[1] http://en.wikipedia.org/wiki/Mandatory_access_control

[2] http://www.nsa.gov/selinux/

[3] http://en.wikipedia.org/wiki/Apparmor

[4] http://news.cnet.com/8301-13580_3-9796140-39.html

[5] http://blogs.msdn.com/michael_howard/archive/2008/01/17/crispin-cowan-joins-the-windows-security-team.aspx

[6] http://blogs.msdn.com/crispincowan/default.aspx

[7] http://news.opensuse.org/2008/08/20/opensuse-to-add-selinux-basic-enablement-in-111/

Share This

Jeronimo Zucco (selinux): openSUSE irá adotar SELinux na versão 11.1

jczucco (noreply@blogger.com) — 2008-08-22T17:28:31+00:00

Foi anunciado na lista opensuse.devel que o SELinux será disponibilizado a partir da versão 11.1 do openSUSE Linux. O AppArmor ainda será a opção default.

Link para o anúncio:

http://article.gmane.org/gmane.linux.suse.opensuse.devel/16096

Yuichi Nakamura: [SELinux]カーネル読書会

himainu — 2008-08-22T15:53:11+00:00

先日のオタワの土産話をしてきた。国際会議にチャレンジしたい気分な人が増えればと思います。会場の楽天さんはとても立派かつスタッフの方々も沢山手伝ってくれていた。楽天さん凄い。 KaiGaiさんの話ピザの前後、KaiGaiさんが話をしていたが、お腹が空いていて、かれいにスルーしてしまいました。ごめんなさい。 PHPのスレッドごとにドメインを割り当て、SQLインジェクションの被害を防げるらしい。 KaiGaiさんの話を試せるサイト： http://kaigai.myhome.cx/index.php ...

James Morris: Nano HOWTO: Getting started with libvirt hacking

2008-08-22T09:20:56+00:00

How to build libvirt from git on Fedora:

mkdir ~/rpmbuild

(cd ~/rpmbuild && mkdir BUILD BUILDROOT RPMS SOURCES SPECS SRPMS)

git clone git://git.et.redhat.com/libvirt.git

cd libvirt

git checkout -b mystuff

export AUTOBUILD_INSTALL_ROOT=$HOME/builder

./autobuild.sh

The above will clone the tree, checkout a branch to hack on, build and test the code, then generate source and binary RPMS. You'll also be set then to do local manual builds.

Thanks to danpb for clues.

Russell Coker (security): DNS Secondaries and Web Security

etbe — 2008-08-21T01:31:24+00:00

At the moment there are ongoing security issues related to web based services and DNS hijacking. the Daily Ack has a good summary of the session hijacking issue [1].

For a long time it has been generally accepted that you should configure a DNS server to not allow random machines on the Internet to copy the entire zone. Not that you should have any secret data there anyway, but it’s regarded as just a precautionary layer of security by obscurity.

Dan Kaminsky (who brought the current DNS security issue to everyone’s attention) has described some potential ways to alleviate the problem [2]. One idea is to use random case in DNS requests (which are case insensitive but case preserving), so if you were to lookup wWw.cOkEr.CoM.aU and the result was returned with different case then you would know that it was forged.

Two options which have been widely rejected are using TCP for DNS (which is fully supported for the case where an answer can not fit in a single UDP packet) and sending requests twice (to square the number of combinations that would need to be guessed). They have been rejected due to the excessive load on the servers (which are apparently already near capacity).

One option that does not seem to get mentioned is the possibility to use multiple source IP addresses, so instead of merely having 2^16 ports to choose from you could multiply that by as many IP addresses as you have available. In the past I’ve worked for ISPs that could have dedicated a /22 (1024 IP addresses) to their DNS proxy if it would have increased the security of their customers - an ISP of the scale that has 1024 spare IP addresses available is going to be a major target of such attacks! Also with some fancy firewall/router devices it would not be impossible to direct all port 53 traffic through the DNS proxies. That would mean that an ISP with 200,000 broadband customers online could use a random IP address from that pool of 200,000 IP addresses for every DNS request. While attacking a random port choice out of 65500 ports is possible, if it was 65500 ports over a pool of 200,000 IP addresses it would be extremely difficult (I won’t claim it to be impossible).

One problem with the consideration that has been given to TCP is that it doesn’t account for the other uses of TCP, such as for running DNS secondaries.

In Australia we have two major ISPs (Telstra and Optus) and four major banks (ANZ, Commonwealth, NAB, and Westpac). It shouldn’t be difficult for arrangements to be made for the major ISPs to have their recursive DNS servers (the caching servers that their customers talk to) act as slaves for the DNS zones related to those four banks (which might be 12 zones or more given the use of different zones for stock-broking etc). If that was combined with a firewall preventing the regular ISP customers (the ones who are denied access to port 25 to reduce the amount of spam) from receiving any data from the Internet with a source port of 53 then the potential for attacks on Australian banks would be dramatically decreased. I note that the Westpac bank has DNS secondaries run by both Optus and Telstra (which makes sense for availability reasons if nothing else), so it seems that the Telstra and Optus ISP services could protect their customers who use Westpac without any great involvement from the bank.

Banks have lots of phone lines and CTI systems. It would be easy for each bank to have a dedicated phone number (which is advertised in the printed phone books, in the telephone “directory assistance” service, and in brochures available in bank branches - all sources which are more difficult to fake than Internet services) which gave a recorded message of a list of DNS zone names and the IP addresses for the master data. Then every sysadmin of every ISP could mirror the zones that would be of most use to their customers.

Another thing that banks could do would be to create a mailing list for changes to their DNS servers for the benefit of the sysadmins who want to protect their customers. Signing mail to such a list with a GPG key and having the fingerprint available from branches should not be difficult to arrange.

Another possibility would be to use the ATM network to provide security relevant data. Modern ATMs have reasonably powerful computers which are used to display bank adverts when no-one is using them. Having an option to press a button on the ATM to get a screen full of Internet banking security details of use to a sysadmin should be easy to implement.

For full coverage (including all the small building societies and credit unions) it would be impractical for every sysadmin to have a special case for every bank. But again there is a relatively easy solution. A federal agency that deals with fraud could maintain a list of zone names and master IP addresses for every financial institution in the country and make it available on CD. If the CD was available for collection from a police station, court-house, the registry of births, deaths, and marriages, or some other official government office then it should not have any additional security risks. Of course you wouldn’t want to post such CDs, even with public key signing (which many people don’t check properly) there would be too much risk of things going wrong.

In a country such as the US (which has an unreasonably large number of banks) it would not be practical to make direct deals between ISPs and banks. But it should be practical to implement a system based on a federal agency distributing CDs with configuration files for BIND and any other DNS servers that are widely used (is any other DNS server widely used?).

Of course none of this would do anything about the issue of Phishing email and typo domain name registration. But it would be good to solve as much as we can.

[1] http://www.dailyack.com/2008/08/cookie-hijacking.html

[2] http://www.doxpara.com/?p=1215

Share This

Yuichi Nakamura: [組込み]BusyBoxの連載記事

himainu — 2008-08-20T13:18:48+00:00

id:hshinjiさんの記事が更新されている。 http://monoist.atmarkit.co.jp/fembedded/index/busyboxtech.html 家電などにも、地味にBusyBoxは載っています。組込みLinuxの必須アイテムです。

Russell Coker (security): Ownership of the Local SE Linux Policy

etbe — 2008-08-19T12:16:35+00:00

A large part of the disagreement about the way to manage the policy seems to be based on who will be the primary “owner” of the policy on the machine. This isn’t a problem that only applies to SE Linux, the same issue applies for various types of configuration files and scripts throughout the process of distribution development. Having a range of modules which can be considered configuration data that come from a single source seems to make SE Linux policy unique among other packages. The reasons for packaging all Apache modules in the main package seem a lot clearer.

One idea that keeps cropping up is that as the policy is modular it should be included in daemon packages and the person maintaining the distribution package of the policy should maintain it. The reason for this request seems to usually be based on the idea that the person who packages a daemon for a distribution knows more about how it works than anyone else, I believe that this is false in most cases. When I started working on SE Linux I had a reasonable amount of experience in maintaining Debian packages of daemons and server processes, but I had to learn a lot about how things REALLY work to be able to write good policy. Also if we were to have policy modules included in the daemon packages, then those packages would need to be updated whenever there were serious changes to the SE Linux policy. For example Debian/Unstable flip-flopped on MCS support recently, changing the policy packages to re-enable MCS was enough pain, getting 50 daemon packages updated would have been unreasonably painful. Then of course there is the case where two daemons need to communicate, if the interface which is provided with one policy module has to be updated before another module can be updated and they are in separate packages then synchronised updates to two separate packages might be required for a single change to the upstream policy. I believe that the idea of having policy modules owned by the maintainers of the various daemon packages is not viable. I also believe that most people who package daemons would violently oppose the idea of having to package SE Linux policy if they realised what would be required of them.

Caleb Case seems to believe that ownership of policy can either be based on the distribution developer or the local sys-admin with apparently little middle-ground [1]. In the section titled “The Evils of Single Policy Packages” he suggests that if an application is upgraded for a security fix, and that upgrade requires a new policy, then it requires a new policy for the entire system if all the policy is in the same package. However the way things currently work is that upgrading a Debian SE Linux policy package does not install any of the new modules. They are stored under /usr/share/selinux/default but the active modules are under /etc/selinux/default/modules/active. An example of just such an upgrade is the Debian Security Advisory DSA-1617-1 for the SE Linux policy for Etch to address the recent BIND issue [2]. In summary the new version of BIND didn’t work well with the SE Linux policy, so an update was released to fix it. When the updated SE Linux policy package is installed it will upgrade the bind.pp module if the previous version of the package was known to have the version of bind.pp that didn’t allow named to bind() to most UDP ports - the other policy modules are not touched. I think that this is great evidence to show that the way things currently work in Debian work well. For the hypothetical case where a user had made local modifications to the bind.pp policy module, they could simply put the policy package on hold - I think it’s safe to assume that anyone who cares about security will read the changelogs for all updates to released versions of Debian, so they would realise the need to do this.

Part of Caleb’s argument rests on the supposed need for end users to modify policy packages (IE to build their own packages from modified source). I run many SE Linux machines, and since the release of the “modular” policy (which first appeared in Fedora Core 5, Debian/Etch, and Red Hat Enterprise Linux 5) I have never needed to make such a modification. I modify policy regularly for the benefit of Debian users and have a number of test machines to try it out. But for the machines where I am a sysadmin I just create a local module that permits the access that is needed. The only reason why someone would need to modify an existing module is to remove privileges or to change automatic domain transition rules. Changing automatic domain transitions is a serious change to the policy which is not something that a typical user would want to do - if they were to do such things then they would probably grab the policy source and rebuild all the policy packages. Removing privileges is not something that a typical sysadmin desires, the reference policy is reasonably strict and users generally don’t look for ways to tighten up the policy. In almost all cases it seems best to consider that the policy modules which are shipped by the distribution are owned by the distribution not the sysadmin. The sysadmin will decide which policy modules to load, what roles and levels to assign to users with the semanage tool, and what local additions to add to the policy. For the CentOS systems I run I use the Red Hat policy, I don’t believe that there is a benefit for me to change the policy that Red Hat ships, and I think that for people who have less knowledge about SE Linux policy than me there are more reasons not to change such policy and less reasons to do so.

Finally Caleb provides a suggestion for managing policy modules by having sym-links to the modules that you desire. Of course there is nothing preventing the existence of a postfix.pp file on the system provided by a package while there is a local postfix.pp file which is the target of the sym-link (so the sym-link idea does not support the idea of having multiple policy packages). With the way that policy modules can be loaded from any location, the only need for sym-links is if you want to have an automatic upgrade script that can be overridden for some modules. I have no objection to adding such a feature to the Debian policy packages if someone sends me a patch.

Caleb also failed to discuss how policy would be initially loaded if packaged on a per-module basis. If for example I had a package selinux-policy-default-postfix which contains the file postfix.pp, how would this package get installed? I am not aware of the Debian package dependencies (or those of any other distribution) being about to represent that the postfix package depends on selinux-policy-default-postfix if and only if the selinux-policy-default package is installed. Please note that I am not suggesting that we add support for such things, a package management system that can solve Sudoku based on package dependency rules is not something that I think would be useful or worth having. As I noted in my previous post about how to package SE Linux policy for distributions [3] the current Debian policy packages have code in the postinst (which I believe originated with Erich Schubert) to load policy modules that match the Debian packages on the system. This means that initially setting up the policy merely requires installing the selinux-policy-default package and rebooting. I am inclined to reject any proposed change which makes the initial install of of the policy more difficult than this.

After Debian/Lenny is released I plan to make some changes to the policy. One thing that I want to do is to have a Debconf option to allow users to choose to automatically upgrade their running policy whenever they upgrade the Debian policy package, this would probably only apply to changes within one release (IE it wouldn’t cause an automatic upgrade from Lenny+1 policy to Lenny+2). Another thing I would like to do is to have the policy modules which are currently copied to /etc/selinux/default/modules/active instead be hard linked when the source is a system directory. That would save about 12M of disk space on some of my systems.

I’ve taken the unusual step of writing two blog posts in response to Caleb’s post not because I want to criticise him (he has done a lot of good work), but because he is important in the SE Linux community and his post deserves the two hours I have spent writing responses to it. While writing these posts I have noticed a number of issues that can be improved, I invite suggestions from Caleb and others on how to make such improvements.

[1] http://www.calebcase.com/node/2

[2] http://lists.debian.org/debian-security-announce/2008/msg00201.html

[3] http://etbe.coker.com.au/2008/08/18/se-linux-policy-packaging-distribution/

Share This

Russell Coker (security): SE Linux Policy Packaging for a Distribution

etbe — 2008-08-18T10:57:10+00:00

Caleb Case (Ubuntu contributer and Tresys employee) has written about the benefits of using separate packages for SE Linux policy modules [1].

Firstly I think it’s useful to consider some other large packages that could be split into multiple packages. The first example that springs to mind is coreutils which used to be textutils, shellutils, and fileutils. Each of those packages contained many programs and could conceivably have been split. Some of the utilities in that package are replaced for most use, for example no-one uses the cksum utility, generally md5sum and sha1sum (which are in the same package) are used instead. Also the pinky command probably isn’t even known by most users who use finger instead (apart from newer Unix users who don’t even know what finger is). So in spite of the potential benefit of splitting the package (or maintaining the previous split) it was decided that it would be easier for everyone to have a single package. The merge of the three packages was performed upstream, but there was nothing preventing the Debian package maintainer from splitting the package - apart from the inconvenience to everyone. The coreutils package in Etch takes 10M of disk space when installed, as it’s almost impossible to buy a new hard drive smaller than 80G that doesn’t seem to be a problem for most users.

The second example is the X server which has separate packages for each video card. One thing to keep in mind about the X server is that the video drivers don’t change often. While it is quite possible to remove a hard drive from one machine and install it in another, or duplicate a hard drive to save the effort of a re-install (I have done both many times) they are not common operations in the life of a system. Of course when you do require such an update you need to first install the correct package (out of about 60 choices), which can be a challenge. I suspect that most Debian systems have all the video driver packages installed (along with drivers for wacom tablets and other hardware devices that might be used) as that appears to be the default. So it seems likely that a significant portion of the users have all the packages installed and therefore get no benefit from the split package.

Now let’s consider the disk space use of the selinux-policy-default package - it’s 24M when installed. Of that 4.9M is in the base.pp file (the core part of the policy which is required), then there’s 848K for the X server (which is going to be loaded on all Debian systems that have X clients installed - due to an issue with /tmp/.ICE-unix labelling [2]). Then there’s 784K for the Postfix policy (which is larger than it needs to be - I’ve been planning to fix this for the past four years or so) and 696K for the SSH policy (used by almost everyone). The next largest is 592K for the Unconfined policy, the number of people who choose not to use this will be small, and as it’s enabled by default it seems impractical to provide a way of removing it.

One possibility for splitting the policy is to create a separate package of modules used for the less common daemons and services, if modules for INN, Cyrus, distcc, ipsec, kerberos, ktalk, nis, PCMCIA, pcscd, RADIUS, rshd, SASL, and UUCP were in a separate package then that would reduce the installed size of the main package by 1.9M while providing no change in functionality to the majority of users.

One thing to keep in mind is that each package at a minimum will have a changelog and a copyright file (residing in a separate directory under /usr/share/doc) and three files as part of the dpkg data store, each of which takes up at least one allocation unit on disk (usually 4K). So adding one extra package will add at least 24K of disk space to every system that installs it (or 32K if the package has postinst and postrm scripts). This is actually a highly optimal case, the current policy packages (selinux-policy-default and selinux-policy-mls) each take 72K of disk space for their doc directory.

One of my SE Linux server sytems (randomly selected) has 23 policy modules installed, if they were in separate packages there would be a minimum of 552K of disk space used by packaging, 736K if there were postinst and postrm scripts, and as much as 2M if the doc directory for each package was similar to the current doc directories). As the system in question needs 5796K of policy modules, the 2M of overhead would make it approach 8M of disk space. So it would only be a saving of 16M over the current situation. While saving that amount of disk space is a good thing, I think that when balanced against the usability issues it’s not worth-while.

Currently the SE Linux policy packages will determine what applications are installed and automatically load policy packages to match. I don’t believe that it’s possible to have a package post-inst script install other packages (and if it is possible I don’t think it’s desirable). Therefore to have separate packages would make a significant difference to the ease of use, it seems that the best way to manage it would be to have the core policy package include a script to install the other packages.

Finally there’s the issue of when you recognise the need for a policy module. It’s not uncommon for me to do some work for a client while on a train, bus, or plane journey. I will grab packages needed to simulate a configuration that the client desires and then work out how to get it going correctly while on the journey. While it would not be a problem for me (I always have the SE Linux policy source and all packages on hand) I expect that many people who have similar needs might find themself a long way from net access without the policy package that they need to do their work. Sure such people could do their work in permissive mode, but that would encourage them to deploy in permissive mode too and thus defeat the goals of the SE Linux project (in terms of having wide-spread adoption).

My next post on this topic will cover the issue of custom policy.

Updated to note that Caleb is a contributor to Ubuntu not a developer.

[1] http://www.calebcase.com/node/2

[2] http://marc.info/?l=selinux&m=121789588709977&w=2

Share This

Yuichi Nakamura: [SELinux] オタワの話

himainu — 2008-08-14T07:39:51+00:00

LWN.netにSMACKの話が載っている。 http://lwn.net/Articles/292291/ ついでに組込みSELinuxとかμ種ITの話も載っている。よい記念になった。

Paul Moore: Fallback Label Configuration Example

2008-08-13T22:00:43+00:00

One of the new features added to the 2.6.25 release of the Linux Kernel was the ability to specify fallback peer labels using NetLabel. This made it possible for system administrators to specify a peer label to be used in the absence of a peer labeling protocol such as CIPSO or Labeled IPsec. In this post I'll try to provide a quick introduction on how to configure NetLabel to provide fallback peer labels.

The first step is to make sure you have all the right kernel and userspace bits in place. Any standard Linux distribution kernel 2.6.25 or greater that has NetLabel support should work. In addition to the kernel you will need to make sure the userspace utility, netlabelctl, supports the new configuration options; this requires netlabel_tools version 0.18 or greater. Once you have verified that you have the right versions installed and running, you can verify everything by running the following commands.

# netlabelctl -p mgmt version
NetLabel protocol version : 2
# netlabelctl -h
NetLabel Control Utility, version 0.18 (libnetlabel 0.18)
 Usage: netlabelctl [<flags>] <module> [<commands>]

 Flags:
   -h        : help/usage message
   -p        : make the output pretty
   -t <secs> : timeout
   -v        : verbose mode

 Modules and Commands:
  mgmt : NetLabel management
    version
    protocols
  map : Domain/Protocol mapping
    add default|domain:<domain> protocol:<protocol>[,<extra>]
    del default|domain:<domain>
    list
  unlbl : Unlabeled packet handling
    accept on|off
    add default|interface:<DEV> address:<ADDR>[/<MASK>]
                                label:<LABEL>
    del default|interface:<DEV> address:<ADDR>[/<MASK>]
    list
  cipsov4 : CIPSO/IPv4 packet handling
    add trans doi:<DOI> tags:<T1>,<Tn>
            levels:<LL1>=<RL1>,<LLn>=<RLn>
            categories:<LC1>=<RC1>,<LCn>=<RCn>
    add pass doi:<DOI> tags:<T1>,<Tn>
    del doi:<DOI>
    list [doi:<DOI>]

The first command checks to see that the kernel speaks version 2 of the NetLabel control protocol which means that it understands the new fallback peer label configuration options. The second command verifies that you have netlabelctl version 0.18 installed and that it supports the fallback configuration commands that we will be using. If everything looks okay it is time to move on to the next step, building a test tool that we can use to verify the configuration. Obviously this isn't a strict requirement for configuring the fallback label mechanism but it is a nice way to verify that your configuration is correct. The test tool I will be using here is a simple little test program I wrote some time ago to test basic peer label functionality for IPv4 TCP sockets, I call it getpeercon_server. Once you have downloaded the C source file you will need to compile it with the following command, if you are on a Fedora system make sure you have the libselinux-devel package installed.

# gcc -o getpeercon_server getpeercon_server.c -lselinux
# ./getpeercon_server
usage: ./getpeercon_server <port>

As you can see the tool is very simple and takes a single argument, the TCP port to bind to a listen for connections. If you start the server on port 5000 and connect to it with telnet, netcat, or some other simple TCP application you should see something similar to what is shown below.

# ./getpeercon_server 5000
-> creating socket ... ok
-> listening on TCP port 5000 ... ok
-> waiting ... connect(127.0.0.1,NO_CONTEXT)
Hello NetLabel Fans!
-> connection closed
-> waiting ...

In the example above we can see that a client connected from localhost, 127.0.0.1, and there was no peer label information provided with the connection, NO_CONTEXT. Now lets configure a fallback peer label for localhost and try it again. Adding a fallback label is relatively simple and can be done with a single command. However, the example below executes two commands. The first command adds a fallback label, "system_u:object_r:netlabel_peer_t:s0", to all traffic coming over the loopback interface, "lo", from localhost, 127.0.0.1. The second command displays all of configured fallback labels; not a necessary step but helpful to ensure that you configured everything correctly.

# netlabelctl unlbl add interface:lo address:127.0.0.1 \
                        label:system_u:object_r:netlabel_peer_t:s0
# netlabelctl -p unlbl list
Accept unlabeled packets : on
Configured NetLabel address mappings (1)
 interface: lo
   address: 127.0.0.1/32
    label: "system_u:object_r:netlabel_peer_t:s0"

Now, lets try our simple connection test again with our newly established fallback label configuration.

# ./getpeercon_server 5000
-> creating socket ... ok
-> listening on TCP port 5000 ... ok
-> waiting ... connect(127.0.0.1,system_u:object_r:netlabel_peer_t:s0)
Fallback Labels Are Really Cool!
-> connection closed
-> waiting ...

If you look at the output you will notice almost everything is the same except for one important thing, instead of NO_CONTEXT the test tool is displaying the fallback label we just configured. The kernel treats the NetLabel fallback label just the same as a normal peer label taken from a CIPSO tag or Labeled IPsec Security Association. This means that not only is the fallback label passed to applications that request it, it is also used when enforcing the LSM's network security policy; in this case SELinux. However, it is important to remember that the fallback labels are overridden by peer labeling protocols. As a result, if both fallback peer label information and Labeled IPsec peer label information is available then the kernel will use the Labeled IPsec peer label information and ignore the fallback peer labels. Fallback peer labels can be configured based on the network interface, network address, and netmask or just network address and netmask when the default network interface is chosen.

Before you start making use of the NetLabel fallback labels, there are a few things you should take into consideration. First, while the fallback functionality was included in Linux Kernel 2.6.25 there was a small bug which prevented some IPv6 fallback labels from being displayed correctly using the "netlabelctl -p unlbl list" command; this has been fixed in kernel 2.6.26. Second, Fedora has not yet adopted version 0.18 of netlabel_tools which means that you will need to download and build netlabelctl separately to take advantage of the new fallback functionality. A Red Hat bugzilla entry has been filed to get the latest netlabel_tools package included in Fedora.

Test tool download: getpeercon_server
NetLabel userspace download: netlabel_tools version 0.18
Fedora bugzilla entry: RH BZ #439833

Caleb Case: Handling of SELinux in Distros Allowing for Controlled Updates and Local Policies

Caleb Case — 2008-08-13T20:43:37+00:00

The current modus operandus of policies as distributed by distros lumps all the policy into one big package. This results in any local policy modifications being wiped away whenever the distro pushes an update to policy. A more ideal situation is to have per module policy packages and a local policy config that allow for per module updates and local policy overrides. Read More

Dan Walsh: Boolean Lockdown Wizard

dwalsh@redhat.com — 2008-08-11T17:48:38+00:00

I have been playing around with a new way of representing booleans. I wanted to create a lockdown wizard, that could be used to to lockdown an SELinux system and then extract the lockdown booleans file, so that you could apply it to multiple machines.

Each section lists the current booleans settings for that module.

You can either enable/disable or restore the default settings on booleans.

You can jump ahead to a particular module.

Try it out by installing
policycoreutils-gui-2.0.52-8.fc9 for Fedora-9
policycoreutils-gui-2.0.54-6.fc10 for Fedora 10.

Run system-config-selinux/choose booleans and select lockdown

The data in the boolean lockdown is generated off of the installed policy. I would like to see the data in the installed policy become more robust so that we could make the tool better. Is there some way we could define what is secure and what is not? Maybe explain what is allowed in more detail when the boolean is turned on and what is denied when it is turned off.

A nice feature of this gui is that in the final step you can make the current machine have the boolean settings and you can save these settings to be applied to other machines.

If you save the settings as boolean_file, you can then copy it to any other Fedora 9 machine and execute

# semanage boolean -m -F boolean_file

We hope to eventually make this part of IPA, So you can destribute your SELinux settings around the environment.

Russell Coker (security): Executable Stacks in Lenny

etbe — 2008-08-10T23:56:08+00:00

One thing that I would like to get fixed for Lenny is the shared objects which can reduce the security of a system. Almost a year ago I blogged about the libsmpeg0 library which is listed as requiring an executable stack [1]. I submitted a two-line patch which fixes the problem while making no code changes (the patch gives the same result as running “execstack -c” on the resulting shared object).

My previous post documents the results of the problem when running SE Linux (a process is not permitted to run and an AVC message is logged). Some people might incorrectly think that this is merely a SE Linux functionality issue.

The program paxtest (which is in Debian but is i386 only) tests for a variety of kernel security features in terms of memory management. To demonstrate the problem that is caused by this issue I ran the commands “paxtest kiddie” and “LD_PRELOAD=/usr/lib/libsmpeg-0.4.so.0 paxtest kiddie“. The difference is that the test named “Executable stack” returns a result of Vulnerable when the object is loaded.

This means for example that attacks which rely on an executable stack will be permitted if the libsmpeg-0.4.so.0 shared object is loaded. So for example a program that loads the library and which takes data from the Internet (EG FreeCiv in network mode) will become vulnerable to attacks which rely on an executable stack because of this bug!

My Etch SE Linux repository has had a libsmpeg0 package which fixes this bug on i386 for almost a year [2] (the AMD64 packages are more recent). I have now added packages to fix this bug to my Lenny SE Linux repository [3]. I have also volunteered to NMU the package for Lenny. It seems that it would be rather embarrassing for everyone concerned systems were vulnerable to attack because of a two-line patch not being applied for almost a year.

I expect that the Release Team will be very accepting of package updates for Lenny which have patches to address this issue. A patch that has one line per assembler file (in the worst-case) to mark the object code is very easy to review. The results of the patch can be tested easily, and failure to have such a patch opens potential security holes. Package maintainers who can’t fix the assembly code can always run “execstack -c” in the build scripts to give the same result.

Lintian performs checks for executable stacks and the results are archived here [4]. There are currently 36 packages which contain binaries listed as needing executable stacks, I would be surprised if more than 6 of them actually contain shared objects that need an executable stack. If you use a package that is on that list then please test whether an executable stack is required by running “execstack -c” on the shared object and see if it still works. If a test of most of the high-level operations of the program in question can be completed successfully without an executable stack then it’s a strong indication that it’s not needed. Note that execstack is in the prelink package. I am happy to help with writing the patches to the packages and using my repositories to distribute the packages, but am not going to do so unless I can work with someone who uses the program in question and can test it’s functions. As an example of such testing I played a game of Frozen Bubble to test out the libsmpeg0 patch.

[1] http://etbe.coker.com.au/2007/10/07/executable-stack-and-shared-objects/

[2] http://etbe.coker.com.au/2007/10/19/my-se-linux-etch-repository/

[3] http://doc.coker.com.au/computers/installing-se-linux-on-lenny/

[4] http://lintian.debian.org/tags/shlib-with-executable-stack.html

Share This

Shintaro Fujiwara: OSC2008 at Nagoya

2008-08-08T13:18:05+00:00

I will be at Nagoya-City University tomorrow.
I will demonstrate SELinux.
Come on everybody !!

http://www.ospn.jp/osc2008-nagoya/

Paul Moore: Linux Foundation Presentation Video

2008-08-04T23:07:27+00:00

Thanks to James Morris for pointing out that the Linux Foundation Japan videos are now online. I've put a copy at the link below. All I ask is that you remember I had been in Japan less than a day when this was filmed and was still dealing with a 13 hour time difference :)

Video download: Introduction to Labeled Networking on Linux

Russell Coker (security): Lenny SE Linux on the Desktop

etbe — 2008-08-04T12:42:45+00:00

I have been asked about the current status of Lenny SE Linux on the Desktop.

The first thing to consider is the combinations of policies and configurations. I will number them if only for the purpose of this post, if the numbering is considered generally helpful it could be more widely adopted to describe configurations.

Default configuration. This has the default policy and is configured with all users having the domain unconfined_t and daemons such as POP servers are allowed to access home directories of type unconfined_home_dir_t. This allows such daemons to attack privileged user accounts.

Some restricted users. This is the same as above but with some users restricted. Daemons such as POP servers are only allowed to access the home directories of restricted users. This means that if a user is to have an unconfined account and receive email they must have two Unix accounts or receive their mail under /var/spool/mail. This is one setsebool command and one (or maybe a few) “semanage login -m” commands from the default configuration.

All users restricted. The system administrator has the domain sysadm_t and users have domains such as user_t. This requires a few more semanage commands. It is equivalent to the old strict policy.

MLS. This is anything that is based around the MLS policy.

Currently I have two Desktop machines running Lenny (a test machine and my EeePC) and one server. I have only just switched my test machine to enforcing mode so have no good data on it (apart from the fact that I can boot it up and login - which is always a good start). The server is running in permissive mode because I have not yet written the policy to allow the POP server to read from unconfined_home_dir_t. I could get it working by switching from level 1 to level 2 or 3, but I want to get level 1 server policy working for the benefit of others else first.

My EeePC however is fully functional, I have been doing some work on it - that mostly means running a ssh client under GNOME but that’s OK (desktop environments such as GNOME and KDE are quite complex and demanding, getting a machine to boot and run such a desktop environment tests out many parts of the system). It’s only at level 1 for the moment because I want to get level 1 working everywhere before moving to the higher levels. I want to get things ready for real users ASAP. With the way the policy is managed now it will be possible to move from level 1 to 2 or 3 without rebooting or interrupting running services. So once users have systems running well at level 1 they can easily increase the security at a later date.

The problems that I have had are due to text relocations in libraries (see my previous post about execmod permission [1]). I’ve filed bug report #493678 against libtheora0 [2] in regard to this issue and included a patch from Fedora (which disables the non-relocatable assembly code in question). It seems that upstream have some new assembler code to try and fix this issue, so hopefully we’ll have something that can make it into Lenny!

I’ve filed bug report #493705 against libswscale0 for the same issue [3]. I included a patch to turn off the assembler code in question but that was not well received. If anyone has some i386 assembler skill and some spare time I would appreciate it if you could try and find a way to make the code position independent while losing little or no performance.

One thing to note is that I am now using an Opteron 1212 (2.0GHz dual-core) system for compiling, I run the i386 DomU with a 64bit kernel (I expect that 32bit user-space runs faster with a 64bit kernel than a 32bit kernel), and the disks are reasonably fast. Even so it takes about 15 minutes to build libswscale0 and the other packages from the same source tree. Previously I was using a 1.0GHz Pentium-3 for my Lenny i386 development until I had the libswscale0 build process go for more than 90 minutes before running out of disk space! If your build machine is old enough to only be 32bit then you should probably plan on watching a movie or going to bed while the build is in progress.

I have built packages that work around the above bugs and included them in my Lenny repository [4]. If you take the packages from that repository plus the Lenny packages then you should have a functional desktop system at level 1. I would appreciate it if people would start testing that and providing feedback. One important issue is the discovery of libraries that want shared stacks, text relocations, and executable memory. The deadline for fixing them properly is even more of a problem due to the number of people who have to be involved in a solution (as compared to the policy where I can do it on my own).

One finally problem is a bug in xdm which causes it to give the wrong context for login sessions due to having an old version of the SE Linux related code [5]. Due to a combination of this and some policy bugs you can not login with xdm. This is not a hugely important issue as most people will use gdm (which has the newer patch) or kdm (which has no SE Linux patch but can use pam_selinux.so). Also another option is wdm which works with pam_selinux.so. I’ve had a response to my bug report suggesting that there’s a bug in the patch (which was taken from gdm so maybe there’s a bug in gdm code too). I haven’t responded to that yet as I’ve been concentrating on the things that will make the most impact for Lenny.

At this stage I’m still unsure of when the release team will cut me off and prevent further SE Linux related fixes from going in Lenny. I need at least one more update to the policy packages before Lenny is released. I could release one right now with some useful improvements over what is currently in unstable, but am waiting until I get some other things fixed.

If I get everything fully working at level 1 (both client and server) before Lenny then I will provide a similar status report for users and testers of levels 2 and 3. I don’t expect that I will even get a chance to test level 4 (MLS) properly before Lenny releases.

[1] http://etbe.coker.com.au/2007/02/10/execmod/

[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493678

[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493705

[4] http://etbe.coker.com.au/2008/07/31/installing-se-linux-on-lenny/

[5] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493524

Share This

Russell Coker (security): Upgrading SE Linux Policy

etbe — 2008-08-02T03:16:06+00:00

When I first packaged the SE Linux policy for Debian the only way to adjust the policy was to edit the source files and recompile. Often changes that you might desire involved changing macros so while it would have been theoretically possible to just tack a few type definitions and allow rules at the end, you often wanted to change a macro to have a change apply all through the policy. To deal with that I had the policy source installed on all machines and the package update policy would compile it into a binary form and load it into the kernel.

Now there was the issue of merging user changes with changes from a new policy package. For most configuration files on a Unix system you can just leave any files that are modified by the user, not taking the new default configuration might cause the user to miss out on some new features - but presumably they were happy with the way it worked in the past. However due to inter-dependencies this wasn’t possible for SE Linux, if one file was not ungraded due to user changes and other files related to it were then the result could be a compile failure.

Another issue was the fact that a newer version of the policy might permit operations that the sys-admin did not desire and therefore not meet their security goals, or it might not permit operations that are essential to the operation of the system and interrupt service.

To solve this I wrote a script that prompted for upgrades to policy source files and allowed the sys-admin to choose which files to upgrade. This worked reasonably well in the early days when the number of files was small. But as the policy increased in size it became increasingly painful to upgrade the policy with as many as 100 questions being asked.

The solution to this (as implemented in Fedora Core 5, Debian/Etch, and newer distributions) was to have binary policy modules that maintain their dependencies. Now there are binary policy modules which can be loaded at will (the default install for Debian only installs modules that match the installed programs) and the modules can have optional sections with dependencies. So if you remove a module that defines a domain and there are other modules which have rules to allow communication with that domain then the optional sections of policy in the other modules is disabled when the domain becomes undefined. This solves the technical issues related to module inter-dependencies but the issue of intent and interaction with the rest of the system remains.

With Red Hat distributions the solution has been to upgrade the running policy every time the policy package is upgraded and be cautious when changing policy. They do a good job of the upgrade process (including relabeling files when the file contexts change) and in terms of policy changes I have not heard complaints from users about that. Users who don’t want a newer version of the policy can always put the package on hold.

For the Debian distribution after Lenny I plan to have a policy upgrade process that relabels files and a debconf question as to whether package upgrades should upgrade the policy. But for Lenny the freeze is already in progress so it seems to late to make such changes. Instead I’m going to upload a new version of the selinux-basics package with a program named selinux-policy-upgrade that will upgrade all the policy modules that are in use. This is not the ideal solution, but I think it will keep Lenny users reasonably happy.

Share This

Russell Coker (security): Postfix and chroot

etbe — 2008-08-02T01:24:23+00:00

I have written a script named postfix-nochroot to disable the chroot functionality of Postfix. I plan to initially include this in the selinux-basics package in Debian, but if the script was adopted by the Postfix package or some other package that seems more appropriate then I would remove it from selinux-basics.

The reason for disabling chroot is that when running SE Linux the actions of the various Postfix processes are restricted greatly, such that granting chroot access would increase the privileges. Another issue is the creation of the chroot environment, the Postfix package in Debian will recreate the files needed for the chroot under /var/spool/postfix when it is started. The first problem with this is that when a package is ugraded the chroot environment won’t be upgraded (with the exceptions of some packages that have special code to restart Postfix) and when the sys-admin edits files under /etc those changes won’t be mirrored in the chroot environment either.

The real problem when running SE Linux is that it requires extra privileges to be granted to the Postfix processes (to be able to call chroot()). While the SE Linux policy places much greater restrictions on the actions of daemons than a chroot would. For example a non-chrooted daemon process running with SE Linux will not be able to see most processes in ps output (it will be able to see that processes exist through entries under

/proc, but without the ability to search the subdirectories of /proc related to other processes it won’t be able to see what they are).

It would be possible for my script to be used as the first step towards making a Postfix installation automatically use a chroot when SE Linux is disabled or in permissive mode, and not use a chroot when SE Linux is in enforcing mode. I’ve probably done about half the work that is needed if this was the end goal, but I have no great interest in such configuration and no time to work on it. I would be prepared to accept patches from other people who want to go in this direction.

Share This

James Morris: LF Japan Symposium Video

2008-08-01T04:36:01+00:00

It seems the videos from the recent LF Japan Symposium are up, including my talk on the SELinux project (139MB FLV). It's really odd seeing yourself giving a talk -- I'm making myself watch so I can see what to try and improve in the future.

And yes, "so" is totally the new "um".

Russell Coker (security): selinux-activate

etbe — 2008-08-01T01:11:18+00:00

I have written a script for Debian named selinux-activate which is included in selinux-basics version 0.3.3+nmu1 (which I have uploaded to Debian/Unstable). The script when run with no parameters will change the GRUB configuration to include selinux=1 on the kernel command-line and enable SE Linux support in the PAM modules for login, gdm, and kdm. One issue with this is that if you run the command before installing kdm or gdm then you won’t have the pam configuration changed - but as it’s OK to run the script multiple times this shouldn’t be a problem.

The new selinux-basics package will also force a reboot after relabelling all filesystems. I had tested “umount -a ; reboot -f” but discovered that “reboot -f” causes filesystem corruption in some situations (my EeePC running an encrypted LVM volume on an SD card had this problem). So I now use a regular “reboot“.

If no-one points out any serious flaws I plan to ask the release team to include this version of selinux-basics in Lenny. I believe that it will make it significantly easier to install SE Linux while also reducing the incidence of systems being damaged due to mistakes. If you edit the GRUB configuration file by hand then there is a risk of a typo making a system unbootable.

The package in question is already in my Lenny repository, see my previous post about Lenny SE Linux for details [1].

[1] http://etbe.coker.com.au/2008/07/31/installing-se-linux-on-lenny/

Share This

Russell Coker (security): Installing SE Linux on Lenny

etbe — 2008-07-31T06:20:18+00:00

Currently Debian/Lenny contains all packages needed to run SE Linux apart from the policy. The policy package is missing because it needs to sit in unstable for a while before migrating to testing (Lenny), and I keep fixing bugs and uploading new versions.

I have set up my own APT repository for SE Linux packages (as I did for Etch [1]). The difference is that it’s working now (for i386 and AMD64) while I released my Etch repository some time after the release of Etch.

gpg --keyserver hkp://subkeys.pgp.net --recv-key F5C75256
gpg -a --export F5C75256 | apt-key add -

To enable the use of my repository you must first run the above two commands to retrieve and install my GPG key (take appropriate measures to verify that you have the correct key).

deb http://www.coker.com.au lenny selinux

Then add the above line to /etc/apt/sources.list and run “apt-get update” to download the list of packages.

Next run the command “apt-get install selinux-policy-default selinux-basics” to install all the necessary packages and then “touch /.autorelabel” to cause the filesystems to be labeled on the next boot. Edit the file /boot/grub/menu.lst and add “selinux=1” to the end of the line which starts with “# kopt=” and then run the command update-grub to apply this change.

Then reboot and the filesystems will be relabeled. Init will be running in the wrong context so you have to reboot again before everything is running correctly (I am thinking of having the autorelabel process automatically do the second reboot).

For future reference please use the page on my documents blog - I will update it regularly as needed [2]. This post will not be changed when it becomes outdated in a few days.

[1] http://etbe.coker.com.au/2007/10/19/my-se-linux-etch-repository/

[2] http://doc.coker.com.au/computers/installing-se-linux-on-lenny/

Share This

Dan Walsh: How do I enable SELinux if I had it disabled?

dwalsh@redhat.com — 2008-07-30T15:08:19+00:00

Say you want to leave the dark side of SELinux disabled and you want to turn it on for the first time. Here are the steps to enable it.

You need to edit the /etc/selinux/config file or use system-config-selinux and change the machine to enforcing or permissive.

If the machine was never labeled or not for a very long time you will probably need to boot in permissive mode. The boot sequence will automatically trigger a relabel, but in enforcing mode there is a good chance that some confined domain (udev?, mount?) will get denied before the system gets a chance to fix the labels.

If you want the machine to be in enforcing mode you can set the flag in the file to enforcing but boot the kernel with the enforcing=0 flag.

reboot.

You should see the machine start the relabeling. The relabeling will output a "*" for each 1000 files it relabels. This should take at least 10 minutes and maybe longer depending on the number of files on your local disks.

Now when the machine finishes booting. You should be ready to login.

If you are running on Fedora 9 your SELinux login setup should look like

# semanage login -l

Login Name                SELinux User              MLS/MCS Range

__default__               unconfined_u              s0-s0:c0.c1023
root                      unconfined_u              s0-s0:c0.c1023
system_u                  system_u                  s0-s0:c0.c1023

If you have something different you cab fix it using the following commands:

# semanage user -a -S targeted -P user -R "unconfined_r system_r" -r s0-s0:c0.c1023 unconfined_u
# semanage login -m -S targeted -s "unconfined_u" -r s0-s0:c0.c1023 __default__
# semanage login -m -S targeted -s "unconfined_u" -r s0-s0:c0.c1023 root
# semanage user -a -S targeted -P user -R guest_r guest_u
# semanage user -a -S targeted -P user -R xguest_r xguest_u

Now you can put the machine into enforcing mode and you should be able to login as a normal user, knowing you have SELinux protecting your system.

Russell Coker (security): SE Linux in Lenny Status

etbe — 2008-07-29T13:39:43+00:00

SE Linux is almost ready to use in Lenny. Currently I am waiting on the packages libsepol1 version 2.0.30-2, policycoreutils 2.0.49-3, and selinux-policy-default version 0.0.20080702-4 to make their way to testing. The first two should get there soon, the policy will take a little longer as I just made a new upload today (to make it correctly depend on libsepol1 and also some policy fixes).

Update: libsepol1 version 2.0.30-2 and policycoreutils 2.0.49-3 are now in Lenny (testing). Now I’m just waiting for the policy.

Ideally we would be able to pin the apt repositories to take just the packages we want from Unstable (here is a document on how it’s supposed to work [1]). That doesn’t work, so I also tried setting “APT::Default-Release “stable”;” in /etc/apt/apt.conf (as suggested on IRC). This gave better results than pinning (which seems to not work at all) but it still wanted to take unreasonably large numbers of packages from unstable.

Currently to get SE Linux in Lenny (Testing) working you must first upgrade everything to the testing versions, then install libsepol1 from Unstable (this is really important as until a few hours ago the Policy packages in Unstable didn’t depend on it). Then you install policycoreutils and finally the policy package which will be selinux-policy-default for almost everyone - I have not tested the MLS package (selinux-policy-mls) and it’s quite likely that it won’t work well.

The policycoreutils package has a bug related to Python libraries [2] which I don’t know how to fix. Any advice would be appreciated. It’s obvious that the package name needs to not contain a hyphen, but what the name should be and where the files should be stored. The release team have been pretty cooperative with my requests so far to get broken things fixed, hopefully I’ll find a solution to this (and the other similar issues) soon enough to avoid any great inconvenience to them. I’m sure that they will agree that significantly broken packages (which have syntax errors in scripts) need to be fixed before release.

There are also some last minute policy issues that need to be fixed. To properly test this I’m now running the server for my blog and mail server on Lenny with SE Linux. I think that I’m only one policy bug away from running in enforcing mode.

While the situation is pretty difficult at the moment (I’ve had a report forwarded to me from an OLS delegate who tried Lenny SE Linux with the older policy packages and got a bad result), I believe that once Lenny is released we will have the best ever support for SE Linux.

The Debian security team recently released an update to the SE Linux policy packages to match the recent updates to BIND [3]. I was grateful that they did this - and without any significant involvement from me. I was asked to advise on the patch that they had written, I confirmed that it looked good (which took hardly any effort), and they did the rest (which appears to be a moderate amount of work). Given the situation it would have been understandable if they had decided that it was something that could be worked around.

I expect that SE Linux on Lenny will get more users than on Etch, so therefore more issues of this nature will be discovered so I expect to have more interaction with the Debian security group in future.

[1] http://jaqque.sbih.org/kplug/apt-pinning.html

[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486120

[3] http://www.debian.org/security/2008/dsa-1617

Share This

Caleb Case: Cuil

Caleb Case — 2008-07-28T14:10:10+00:00

I just tried Cuil for the first time and I have to admit I'm left wanting. A common search for me is "wiki <something>". I do this mainly because Wikipedia's own search engine isn't serviceable. However, running a similar search through Cuil netted me nada. Not only did it fail to find me what I wanted, but it also failed to do so in a timely manner. The search is sloooooooow. Which I suspect might have something to do with it Cuil showing up on Google News today (and hence may be experiencing some rather large traffic). Even still, it looks like the engine is pulling down images from the websites is finds to display next to their links and summaries (which takes time and can result in the page simply not ever finishing to load). Which leaves me with the interface. I do _not_ want 3 columns that I have to scroll. Now if they had given me, say, the option to shrink the summaries, eliminate the pictures, make everything fit on a single screen without scrolling, and shortcut keys for switching to the next page... well then maybe. As it stands, I'd say its pretty much unusable.

Russell Coker (security): Biba and BLP for Network Services

etbe — 2008-07-28T09:00:50+00:00

Michael Janke has written an interesting article about data flows in networks [1], he describes how data from the Internet should be considered to have low integrity (he refers to it as “untrusted”) and that as you get closer to the more important parts of the system it needs to be of higher integrity.

It seems to me that his ideas are very similar in concept to the Biba Integrity Model [2]. The Biba model is based around the idea that a process can only write data to a resource that is of equal or lower integrity and only read data from a resource that is of equal or higher integrity, this is often summarised as “no read-down and no write-up“. In a full implementation of Biba the OS would label all data (including network data) as to it’s integrity level and prevent any communication that violates the model (except of course for certain privileged programs - for example the file or database that stores user passwords must have high integrity but any user can run the program to change their password). A full Biba implementation would not work for a typical Internet service, but considering some of the concepts of Biba while designing an Internet service should lead to a much better design (as demonstrated in Michael’s post).

While considering the application of Biba to network design it makes sense to also consider consider the Bell LaPadula model (BLP) [3]. In computer systems designed for military use a combination of Biba and BLP is not uncommon, while a strict combination of those technologies would be an almost insurmountable obstacle to development of Internet services I think it’s worth considering the concepts.

BLP is a system that is primarily designed around the goal of protecting data confidentiality. Every process (subject) has a sensitivity label (often called a “clearance”) which is comprised of a sensitivity level and a set of categories and every resource that a process might access (object) also has a sensitivity label (often called a “classification”). If the clearance of the subject dominates the classification of the object (IE the level is equal or greater and the set of categories is a super-set) then read access is permitted, if the clearance of the subject is dominated by the classification of the object then write access is permitted, and the clearance and classification have to be equal for read/write access to be permitted. This is often summarised as “no write-down and no read-up“.

SGI has published a lot of documentation for their Trusted Irix (TRIX) product on the net, the section about mandatory access control covers Biba and BBLP [4]. I recommend that most people who read my blog not read the description of how Biba and BLP works, it will just give you nightmares.

The complexity of either Biba or BLP (including categories) is probably too great for consideration when designing network services which have much lower confidentiality requirements (even the loss of a few million credit card numbers is trivial compared to some of the potential results of leaks of confidential military data). But a simpler case of BLP with only levels is worth considering. You might have credit card numbers stored in a database classified as “Top Secret” and not allow less privileged processes to read from it. The data about customers addresses and phone numbers might be classified as “Secret” and all the other data might merely be “Classified”.

One way of using the concepts of Biba and BLP in the design of a complex system would be to label every process and data store in the system according to it’s integrity and classification/clearance. Then for the situations where data flows to processes with lower clearance the code could be well designed and audited to ensure that it does not leak data. For situations where data of low integrity (EG data from a web browser) is received by a process of high integrity (EG the login screen) the code would have to be designed and audited to ensure that it correctly parsed the data and didn’t allow SQL injection or other potential attacks.

I expect that many people who have experience with Biba and BLP will be rolling their eyes while reading this. The situation that we are dealing with in regard to PHP and SQL attacks over the Internet is quite different to the environments where proper implementations of Biba and BLP are deployed. We need to do what we can to try and improve things, and I think that the best way of improving things in terms of web application security would involve thinking about clearance and integrity as separate issues in the design phase.

[1] http://lastinfirstout.blogspot.com/2008/07/presumed-hostile-your-application-is.html

[2] http://en.wikipedia.org/wiki/Biba_Integrity_Model

[3] http://en.wikipedia.org/wiki/Bell-LaPadula_model

[4] http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=bks&fname=/SGI_EndUser/books/TCMW_UG/sgi_html/ch02.html

Share This

Yuichi Nakamura: [SELinux] Linux Symposium　最終日

himainu — 2008-07-26T18:31:01+00:00

Smackの発表 Smackネ申が、Smackのシンプルっぷりを力説。途中、SELinux軍団からツッコミが何度も入る。以下話の内容を列挙。 Smackは、MAC（データへのアクセス制御)のみを提供。settimeofdayなど特権は範囲外。特権はcapabilityを使ってくれとのこと Smackのアクセス制御モデル。図解だと一目で分かった。システムラベル3種類_、^、*。 _は、全てのsubjectからreadonly, ^は全てのobjectにreadアクセス、*は、全てのs ...

Caleb Case: Source code highlighting!

Caleb Case — 2008-07-26T03:10:05+00:00

class Lambda():
        pass
 
conf = Lambda()
conf.source = Lambda()
conf.source.highlight = True
 
def clap():
        print("*clap*\n" * 3)
 
if conf.source.highlight is True:
        clap()

....

Ok that was silly, but you get the idea. Source code highlighting is available (even in the comments):

<code type="python">
...
</code>

Check out the input filter tips for more information on using the source code highlighter.

Yuichi Nakamura: [SELinux] Linux Symposium 3日目

himainu — 2008-07-25T19:07:06+00:00

私の発表終わった！！質問がいくつかあった。 μ種ITはLabeled Networkをサポートしてるのか？ Labeled networkのほうがパフォーマンス出ると思うよと言っていた気がするのだが。。。 Androidの仕事はオープンなのか？ Montavistaのmicro SELinuxとの関係は？など。micro SELinuxは、他でも聞かれる。micro SELinuxは中身は不明だが、SELinuxの布教としては良かったようだ。 Joshua Brindle氏に、呼 ...

James Morris: OLS Slides + Macbook fail

2008-07-25T09:59:24+00:00

Here are the slides from my OLS talk, although the paper is way more useful.

For those who attended Dan Walsh's talk on confining the user, you can find the slides here. Quite a few people expressed interest in them during the talk, and Dan sent them to me for some reason, so there you go.

***

Btw, my MacBook seems to never work with projectors (thanks to Paul Moore for lending me his laptop for the talk). It's relatively recent and has the following graphics stuff:
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
Nothing seems to work: rebooting with the cable attached (VGA text mode works, but not X), exhaustive messing about with xrandr, hitting the laptop with a hammer etc. Does anyone know something else I can try?

Paul Moore: SELinux Developer's Summit 2008

2008-07-25T01:41:02+00:00

I'm at OLS right now, but the day before OLS started we held this year's SELinux Developer's Summit as part of OLS's mini-summit program. This year's summit was a bit of a departure from previous years in that the summit consisted of several short presentations and was open to everyone. Personally, I thought it went very well, with lots of good work-in-progress presentations, my favorite kind, and plenty of discussion. My own contribution, an update on the state of SELinux Labeled Networking, can be found below. James Morris has posted all of the slides on the schedule page, so you can check out what was discussed if you weren't able to make it to Ottawa this year.

Hopefully we will be able to continue having regular SELinux Developer Summits in the future that are similar to the one this year. There is even some talk about extending future summits to include both a presentation day and a hack-fast day. I can't remember who proposed the hack-fest day, but I like it. Especially if we hold it in Hawaii :)

Presentation download: State of SELinux Labeled Networking

Paul Moore: The Importance of Documentation

2008-07-24T23:00:53+00:00

When I think about all of the items on my Linux Labeled Networking todo list one of the items that stands out the most is the lack of good, useful documentation. Oh sure, there is some documentation available, for instance Joshua Brindle's blog post about Labeled IPsec on SELinux, but most of it is quickly becoming dated and no longer a good fit with current kernels and tools. A big part of the problem is the amount of ongoing development which makes it difficult to spend much time writing documentation. I've managed to convince myself that development of user requested features is more important than documentation, but I suppose that does little to help people who are trying to use and configure the existing labeled networking features.

While I still think development is more important, we still have a lot of usability functionality to implement, I am going to try and do a better job of documenting the Linux Labeled Networking features. Part of that effort is the creation of this blog where I plan to talk about Linux Labeled Networking development and related topics. To kick things off I've posted slides from a presentation I gave earlier this week at the Linux Foundation's Japan Symposium, the presentation is designed to be a quick introduction to labeled networking on Linux including overviews of Secmark, NetLabel, and Labeled IPsec.

Presentation download: Introduction to Labeled Networking on Linux

Yuichi Nakamura: [SELinux] Linux Symposium二日目

himainu — 2008-07-24T19:44:52+00:00

James Morrisの講演 James Morrisの話があった。ここ1，2年のSELinuxの進歩についての講演。種ITやKaiGaiさんの仕事とかも紹介されてた。周りを見渡してみると、ジオ（モビルスーツ）のような人が非常に多い。が、席の広さは日本とかわらないのが不思議。隣に座られると動けジオ！って感じ。メタボな人に対して人種差別的な扱いをしている我が国はグローバル化に出遅れてますな。 SELinuxネ申とホテルが同じで、エレベータで遭遇し、対話してしまった。日本のSELinux開発の状況 ...

Planet SELinux

Shintaro Fujiwara: segatex-6.70 ??

Dan Walsh: Top three things to understand in fixing SELinux problems.

Yuichi Nakamura: [SELinux]先日のオタワのレポート記事

Yuichi Nakamura: [SELinux] OpenSuseにSELinux

Yuichi Nakamura: [SELinux] レッドハットやFedora Projectのサーバに不正侵入

Russell Coker (security): Is SE Linux Unixish?

Russell Coker (security): Play Machine Downtime

Russell Coker (security): AppArmor is Dead

Jeronimo Zucco (selinux): openSUSE irá adotar SELinux na versão 11.1

Yuichi Nakamura: [SELinux]カーネル読書会

James Morris: Nano HOWTO: Getting started with libvirt hacking

Russell Coker (security): DNS Secondaries and Web Security

Yuichi Nakamura: [組込み]BusyBoxの連載記事

Russell Coker (security): Ownership of the Local SE Linux Policy

Russell Coker (security): SE Linux Policy Packaging for a Distribution

Yuichi Nakamura: [SELinux] オタワの話

Paul Moore: Fallback Label Configuration Example

Caleb Case: Handling of SELinux in Distros Allowing for Controlled Updates and Local Policies

Dan Walsh: Boolean Lockdown Wizard

Russell Coker (security): Executable Stacks in Lenny

Shintaro Fujiwara: OSC2008 at Nagoya

Paul Moore: Linux Foundation Presentation Video

Russell Coker (security): Lenny SE Linux on the Desktop

Russell Coker (security): Upgrading SE Linux Policy

Russell Coker (security): Postfix and chroot

James Morris: LF Japan Symposium Video

Russell Coker (security): selinux-activate

Russell Coker (security): Installing SE Linux on Lenny

Dan Walsh: How do I enable SELinux if I had it disabled?

Russell Coker (security): SE Linux in Lenny Status

Caleb Case: Cuil

Russell Coker (security): Biba and BLP for Network Services

Yuichi Nakamura: [SELinux] Linux Symposium 最終日

Caleb Case: Source code highlighting!

Yuichi Nakamura: [SELinux] Linux Symposium 3日目

James Morris: OLS Slides + Macbook fail

Paul Moore: SELinux Developer's Summit 2008

Paul Moore: The Importance of Documentation

Yuichi Nakamura: [SELinux] Linux Symposium二日目

Yuichi Nakamura: [SELinux] Linux Symposium　最終日