Planet SELinux

Dan Walsh: SELinux and Chrome followup.

dwalsh@redhat.com — 2008-09-05T12:38:22+00:00

Just reading though http://selinuxnews.org/planet/ I noticed that Joshua Brindle and Russell Coker have both blogged on using SELinux and Chrome together. Both do a better job describing what could be done then I did.

What is the old expression

Great Minds Think Alike (Fools Seldom Differ?)

James Morris: Memory protections followup

2008-09-04T23:53:36+00:00

Following up on a couple of the comments on my last entry on SELinux memory protections vs. Zend Optimizer:

The policy does indeed look like it was generated automatically by audit2why or similar. This very clearly highlights a core problem with "learning mode" security schemes, which can blindly encapsulate dangerous behavior in a buggy application, or even an attack in progress. This issue was previously expounded by Josh Brindle in Status Quo Encapsulation.

Such techniques do have their place, although it is always recommended that such resulting policy be reviewed. Again, it is easy to find help.

It's unfortunate that some vendors promote automated policy generation schemes as a core usability feature, leading many people to assume that this is a great idea, and even the way things are supposed to work.

Of course, nobody would ever capitalize on peoples' combined fear and lack of expertise in an area and sell a "miracle" solution which doesn't quite work. No, that would never happen.

As H.L. Mencken and some character on the single episode of CSI I suffered through said: "... there is always an easy solution to every problem — neat, plausible and wrong.".

The idea that the problem of OS security can be solved effortlessly with the click of a mouse should be raising alarm bells in everyone's heads by now, surely ?

Dan Walsh: SELinux and Chrome

dwalsh@redhat.com — 2008-09-04T18:50:05+00:00

After reading the Google Chrome announcement/comic book, I got to thinking

How could SELinux and Chrome work together?

The comic book says that Chrome can run each tab in a different processes, allowing you to isolate processes from each other. If a tab processes crashes because of a bug it will only bring down that tab, not the entire web browser. We have this in Fedora 9, in that we can run most of the plug-ins in a separate processes from Firefox, nsplugin. If a plug-in causes the process to crash, the nsplugin program crashes not Firefox.  You can use SELinux to lock down the nsplugin process to prevent it from attacking our system. The nice thing from an SELinux point of view is that we did not need to change Firefox to make this happen. Since Firefox executed nsplugin (npviewer.bin), we can write policy that says when a user (unconfined_t) execs an executable labeled nsplugin_exec_t, SELinux will transition to process labeled nsplugin_t.

With Chrome we might be able to take this further. Imagine Chrome could differentiate between external and internal web sites, then the main Chrome processes could create two tabs running under different SELinux contexts. Say chrome_trusted_t and chrome_untrusted_t, You could isolate these processes from each other and maybe allow chrome_trusted_t to read and write anywhere on the file system while chrome_untrusted_t could only read/write the ~/untrusted directory, labeled untrusted_content_home_t.   With labeled networking you could set up a proxy server that would only accept connections from processes labeled chrome_untrusted_t. If a user is reading a Company Confidential web site in one tab, and connected to www.espn.com on another tab, SELinux would prevent the untrusted tab from reading the trusted tabs content.

This would require changes to Chrome code, but the SELinux code to do this is fairly simple.

Pseudo Code

Depending on how Chrome works.

User enters an external web site:

If chrome just forks a new process it would:

child = fork();
if (Child) {
            if (selinux_is_enabled()) {
                      setcontext("user_u:user_r:chrome_untrusted_t");
                      ... /* Run the tab process */
                      exit()
            }
}

or

if chrome forks and execs a new process.

child = fork();
if (Child) {
            if (selinux_is_enabled()) {
                      setexeccon("user_u:user_r:chrome_untrusted_t");
                      exec() /* exec the tab process */

                      setexeccon(NULL); /* This sets that system back to default behaviour, if exec failed */
            }
}

Policy would have to be written to allow a transition from unconfined_t to chrome_untrusted_t, since the kernel will verify all transitions.

Any enterprising grad students looking for a project?

I could imagine similar changes could be done in Apache (mod_*), sshd, Samba.

James Morris: SELinux memory protections are your friend

2008-09-04T14:54:24+00:00

I don't know what a Zend Optimizer is, but it apparently does not play well with SELinux. I've encountered a blog entry by someone who has tried to do the right thing and keep SELinux enabled, after finding the code for a policy module which makes this stuff work.

I was surprised when I saw the source of the module, which includes:


allow httpd_t self:process execstack;
allow httpd_t self:process execmem;
allow httpd_t self:process execheap;
allow httpd_t usr_t:file execute;

When loaded, this will enable the web server to execute memory on its heap, stack or certain types of executable memory allocated via mmap(2). These are well-known attack vectors and disable some very important memory protection mechanisms. See Ulrich Drepper's SELinux Memory Protection Tests for details.

The file execute permission is also very concerning, as it allows the web server to execute generically labeled user files. Combined with disabled memory protections, and third-party software using unsafe memory execution techniques, I'd recommend being cautious about deploying this solution.

What I would suggest, if you don't understand the security policy, is to run it by your nearest SELinux community. Many mailing lists and IRC channels exist where people will be able to help: see User Resources from the SELinux Project Wiki.

It's important to note that whatever this code is supposed to be doing (apparently, dealing with some form of source code obfuscation), techniques such as making a stack executable are inherently insecure and should never be necessary.

SELinux really is trying to help you here, and free expert advice is merely an email away. At the very least, someone will be able to explain what the risks are, and help you make an informed decision on how to proceed: perhaps it will be better for your particular requirements to allow certain accesses rather than disabling SELinux for the entire system. And if the code is not trying to do something dangerous, an SELinux developer may write a simple module for you to load to work around the issue.

Yuichi Nakamura: [その他]XDev2008に行ってきた

himainu — 2008-09-04T14:22:46+00:00

三浦さんと対談してきた。対談というのは初体験だったので、緊張しましたが面白かったです。 http://itpro.nikkeibp.co.jp/article/NEWS/20080904/314176/ 聞きに来てくださった方、三浦さん、日経BPの方々、ありがとうございました。

Yuichi Nakamura: [SELinux][AppArmor] AppArmor死亡確認？

himainu — 2008-09-04T14:12:39+00:00

Russellのblogで、AppArmor死亡説がとなえられた。 http://etbe.coker.com.au/2008/08/23/apparmor-is-dead/ で、大量にコメントがついてた。コメントでは、SELinuxへの不満の声も見られる。で、なんと、MSに逝かれたAppArmorの元ネ申が、ブログで反応。 http://blogs.msdn.com/crispincowan/archive/2008/09/02/go-ahead-make-my-day.aspx ちょっと誇張し ...

Russell Coker (security): Random Opinions, Expert Opinions, and Facts about AppArmor

etbe — 2008-09-04T10:52:30+00:00

My previous post titled AppArmor is Dead [1] has inspired a number of reactions. Some of them have been unsubstantiated opinions, well everyone has an opinion so this doesn’t mean much. I believe that opinions of experts matter more, Crispin responded to my post and made some reasonable points [2] (although I believe that he is overstating the ease of use case). I take Crispin’s response a lot more seriously than most of the responses because of his significant experience in commercial computer security work. The opinion of someone who has relevant experience in the field in question matters a lot more than the opinion of random computer users!

Finally there is the issue of facts. Of the people who don’t agree with me, Crispin seems to be the first to acknowledge that Novell laying off AppArmor developers and adding SE Linux support are both bad signs for AppArmor. The fact that Red Hat and Tresys have been assigning more people to SE Linux development in the same time period that SUSE has been laying people off AppArmor development seems to be a clear indication of the way that things are goind.

One thing that Crispin and I understand is the amount of work involved in maintaining a security system. You can’t just develop something and throw it to the distributions. There is ongoing work required in tracking kernel code changes, and when there is application support there is also a need to track changes to application code (and replacements of system programs). Also there is a need to add new features. Currently the most significant new feature development in SE Linux is related to X access controls - this is something that every security system for Linux needs to do (currently none of them do it). It’s a huge amount of work, but the end result will be that compromising one X client that is running on your desktop will not automatically grant access to all the other windows.

The CNET article about Novell laying off the AppArmor developers [3] says ‘“An open-source AppArmor community has developed. We’ll continue to partner with this community,” though the company will continue to develop aspects of AppArmor‘ and attributes that to Novell spokesman Bruce Lowry.

Currently there doesn’t seem to be an AppArmor community, the Freshmeat page for AppArmor still lists Crispin as the owner and has not been updated since 2006 [4], it also links to hosting on Novell’s site. The Wikipedia page for AppArmor also lists no upstream site other than Novell [4].

The AppArmor development list hosted by SUSE is getting less than 10 posts per month recently [6]. The AppArmor general list had a good month in January with a total of 23 messages (including SPAM) [7], but generally gets only a few messages a month.

The fact that Crispin is still listed as the project leader [8] says a lot about how the project is managed at Novell!

So the question is, how can AppArmor’s prospects be improved? A post on linsec.ca notes that Mandriva is using AppArmor, getting more distribution support would be good [9], but the most important thing in that regard will be contributing patches back and dedicating people to do upstream work (Red Hat does a huge amount of upstream development for SE Linux and a significant portion of my Debian work goes upstream).

It seems to me that the most important thing is to have an active community. Have a primary web site (maybe hosted by Novell, maybe SourceForge or something else) that is accurate and current. Have people giving talks about AppArmor at conferences to promote it to developers. Then try to do something to get some buzz about the technology, my SE Linux Play Machines inspired a lot of interest in the SE Linux technology [10]. If something similar was done with AppArmor then it would get some interest.

I’m not interested in killing AppArmor (I suspect that Crispin’s insinuations were aimed at others). If my posts on this topic inspire more work on AppArmor and Linux security in general then I’m happy. As Crispin notes the real enemy is his employer (he doesn’t quite say that - but it’s my interpretation of his post).

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

[2] http://blogs.msdn.com/crispincowan/archive/2008/09/02/go-ahead-make-my-day.aspx

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

[4] http://freshmeat.net/projects/apparmor/

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

[6] http://forge.novell.com/pipermail/apparmor-dev/

[7] http://forge.novell.com/pipermail/apparmor-general/

[8] http://forge.novell.com/modules/xfmod/project/memberlist.php?group_id=1864

[9] http://linsec.ca/blog/2008/09/03/crispin-responds-to-allegations-that-apparmor-is-dying/

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

Share This

Dan Walsh: Nasty SELinux redirection AVC's

dwalsh@redhat.com — 2008-09-03T16:22:01+00:00

One of the things that makes SELinux hard to understand is it's handling of shell redirection. A query on the Fedora SELinux list by Richard Johnson asks about how to handle SELinux avc's when redirection rpm output.

When installing a policy rpm, one cannot log the install activity w/o generating avc errors. For example:

rpm -i lsb-ft-asn-selinux > /var/log/rpm-update.log

produces the following violation:

type=SYSCALL msg=audit(1219774608.030:789): arch=c000003e syscall=59 success=yes exit=0 a0=be952e0 a1=be93390 a2=be958f0 a3=8 items=0 ppid=2848 pid=2875 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS1 ses=2 comm="restorecon" exe="/sbin/restorecon" subj=root:system_r:restorecon_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1219774608.030:789): avc: denied { write } for pid=2875 comm="restorecon" path="/var/log/rpm-update.log" dev=md2 ino=2694055 scontext=root:system_r:restorecon_t:s0-s0:c0.c1023 tcontext=root:object_r:var_log_t:s0 tclass=file

The problems seems to stem from recording the %post script's attempts to relabel files affected by the policy, specifically:

/sbin/restorecon -F -R -v /opt/ft/sbin/sra_alarm;
/sbin/restorecon -F -R -v /etc/opt/ft/asn;
/sbin/restorecon -F -R -v /var/opt/ft/asn;
/sbin/restorecon -F -R -v /var/opt/ft/log;

So what is going on here?

The shell is creating a /var/log/rpm-update.log. Most likely the process that is running the shell is running as unconfined_t, and unconfined_t does not have a transition rule for files in var_log_t directories. (var_log_t is the label of the /var/log directory) The rpm-update.log file gets created with the var_log_t label. The shell opens the file for write and redirects the stdout of rpm and all of its children process to this file.

When rpm is started it transitions to rpm_t and the SELinux kernel checks if rpm_t is able to write to files labeled var_log_t, since rpm_t is an unconfined domain it is allowed. rpm will hand the open file descriptor to all of its decendants. rpm executes it's scripts as rpm_script_t (Also unconfined). When rpm_script_t executes an application with a transition rule define, the SELinux kernel checks to see if the new domain is allowed to write to var_log_t.

In the case above rpm_script_t transitions to restorecon_t when it execs files labeled restorecon_exec_t. The SELinux kernel checks if restorecon_t is allowed to write to a file labeled var_log_t, restorecon_t is not allowed so the kernel reports the AVC. It also closes the open file descriptor and replaces it with a file descriptor to /dev/null. restorecon is then started and actually runs to a successfull completion, however no output with go to rpm-update.log.

So what should the admin do about this?

I can think of a few choices.

He can ignore it. Since the restorecon does not need to output anything, the installation completed and the AVC's are basically meaningless. He can even tell setroubleshoot to not show the AVC's/
He can add a local custom policy module, to allow domains to output to var_log_t, Using audit2allow -M mypol
- rpm -i lsb-ft-asn-selinux >> /var/log/rpm-update.log
- would be better since it will only add append.
He attempt to find a label for file and label it correctly such that all domains can append to it. rpm_log_t might work.
He can stick a cat in the middle of the command
- rpm -i lsb-ft-asn-selinux | cat > /var/log/rpm-update.log
- In this case bash opens the file as var_log_t and hands the open descriptor to cat which is also running as unconfined_t, but in this case bash sets the commands stdout to be a open fd descriptor to a unconfined_t. Most domains can "use" unconfined_t fd, so the AVC dissapears.

Fedora 10 - OPEN access check to the rescue:

This is a difficult thing to comprehend and we are trying to eliminate some of these AVC's. SELinux in Fedora 10 has added an OPEN check. This checks whether an application actually attempts to open a file rather then just tries to read/write the file. Before the OPEN check policy writers were not able to differentiate between an application actually actively going out and opening files versus being handed open file descriptors from processes like the shell.

So in Fedora 10 we will allow confined applications to read/write files in places users commonly redirect output. (user_home_t, user_tmp_t, logfiles). While denying the "open" access. If you see an OPEN access being denied, you should be very wary of this access and really investigate what is going on. If a cracker broke into a confined domain and got to a shell, he would probably be actively attempting to OPEN files.

Yuichi Nakamura: [SELinux] 開発体制変更

himainu — 2008-09-03T11:55:49+00:00

いつのまにやら、開発体制というか環境が変わっている。開発ポータルユーザランドの開発のポータルが↓のサイトに移ったようだ http://oss.tresys.com/projects/selinux 他にも、 http://selinuxproject.org/page/Main_Page というページがあるが、関係がよく分からない。 refpolicyメーリングリスト refpolicyに関する議論は、refpolicy mlに移った模様。 http://oss.tresys.com/mail ...

Yuichi Nakamura: [組込み] gccの小技集

himainu — 2008-09-03T11:55:48+00:00

ELC2008における、Gene Sally氏の発表をまとめたもの。結構この手の小技って、職場毎に一子相伝的に受け継がれていて、色々と隠れている気がする。 http://elinux.org/GCC_Tips

Joshua Brindle: Web browsers, security and Google Chrome

Joshua Brindle — 2008-09-03T00:15:09+00:00

Securing web browsers has always been a little tricky. With so many web applications available today, including corporate intranet sites, email and so on with confidential or proprietary information it is always a bit troublesome that web browsers essentially run in one security domain. The last thing I want is for a teller at my bank to go to some site that ends up getting bank info from another tab.

There have been several improvements in the web browsing space though. Microsoft Internet Explorer has protected mode but that doesn’t use system based access control to enforce separation of internal web pages from external ones, for example. On Linux we’ve started using nsplugin to load plugins (flash, whatever) into a separate process. This is particularly nice on SELinux systems since we can transition those plugins into a domain that can’t do much, such as read files in home directories, access the network, etc. Dan Walsh has a nice writeup about this at his blog

That still doesn’t separate sites of differing security domains (my bank, joke site my friend sent in an email, the company sharepoint server, etc) into separate processes that cannot interact with each other.

I had a customer once that actually augmented Firefox to be a multi-level browser. This was a Trusted Solaris solution and really didn’t address the problem. All of the sites were still inside the same browser process and they had only augmented it to try and keep that data separate. Something that used process and domain separation would be better. If we trusted the web browser to not leak data none of this would be necessary!

The best we can hope for is manually separating browsers. I’ve blogged in the past about using network access controls in SELinux to ensure an ‘internal’ browser can’t browse the the internet, and an ‘internet’ browser can’t browse into the intranet. This requires user intervention to understand and keep track of multiple browsers, hardly an elegant solution. Surely there is a better way.

Now comes Google Chrome, a shiny (haha) new browser that has some great ideas. Google also published an interesting set of comics that describe some of the ideas and features.

The ones I found most interesting: Each tab is rendered in a separate process, plugins run in a separate process and a javascript virtual machine. This means tabs shouldn’t be able to get data from other tabs (now I don’t have to worry about crazy scary Myspace pages reading my bank account number).

There are a couple things to worry about, first they claim plugins are poorly written and therefore must have access to all tabs (which is particularly scary given the Flash vulnerabilities as of late). The ideal solution is to have a plugin process per-rendering process, this would keep plugins from interacting with each other and other rendering processes. They claim this is a long term goal, that they would work with plugin writers to make this easier, we can only hope.

Second, and much more worrisome is on slide 29, the claim that they know their sandboxing works because they wrote it, wrong! If we trusted the applications to begin with we’d have no need for additional access control.

Now all this brings me to my main point. Granted Chrome is only available for Windows at the moment but hopefully it’ll be available on Linux before long. And then we might have something interesting to work on. Different security domains for different sites? That would be great. Different domains for plugins? Yes! SELinux enforced sandboxes?

So here is the idea: We label sites by dns name or IP and have Chrome execute the rendering processes in different domains. *.tresys.com would run in internal_website_t and not be able to send data to the internet! my bank site would run in bank_website_t and only be able to send data to my banks address. Even if I have some sort of browser or plugin exploit going on it won’t matter, only data can be sent to the appropriate place (this is the beauty of mandatory access control, even a broken application can’t do anything bad). This should work because Chrome even creates new rendering processes if you jump from one domain to another (It does this today). If I go to facebook and then to myspace in the same tab a new process is created for myspace. I’d like to go so far as to put the javascript vm in another process, since it is executing dynamically generated code, or else we’ll have to give the rendering process the ability to execheap, execstack, not a good permission to give something already susceptable to vulnerabilities.

What is the net result of this? It is like the manual separation I and others have talked about before but from the user perspective it is seamless. Tabs in the same browser running in different security domains without the users knowledge, seamless mandatory security on web browsing, I can’t wait!

If this should happen to reach any of the Chrome developers I’d love to talk to you about the possibilites. Combining this browser (which is excellent BTW, I’m using it to write this blog post) with the mandatory separation afforded by SELinux would make an incredibly powerful platform for securing web applications.

Dan Walsh: I am backup on planet.fedoraproject.org

dwalsh@redhat.com — 2008-09-02T19:16:13+00:00

When fedoraproject.org site was rebuilt in the last couple of weeks, I guess I missed the message that you needed to put a .planet file in your people.fedoraproject.org home dir in order to have the planet see your blogs, sorry about that. Well I have fixed this. But you might have missed some of my blogs. The best one, IMHO, was:

Top three things to understand in fixing SELinux problems

So here is a link to it.

Back to Bugzilla.

Russell Coker (security): Google Chrome - the Security Implications

etbe — 2008-09-02T12:44:35+00:00

Google have announced a new web browser - Chrome [1]. It is not available for download yet, currently there is only a comic book explaining how it will work [2]. The comic is of very high quality and will help in teaching novices about how computers work. I think it would be good if we had a set of comics that explained all the aspects of how computers work.

One noteworthy feature is the process model of Chrome. Most browsers seem to aim to have all tabs and windows in the same process which means that they can all crash together. Chrome has a separate process for each tab so when a web site is a resource hog it will be apparent which tab is causing the performance problem. Also when you navigate from site A to site B they will apparently execute a new process (this will make the back-arrow a little more complex to implement).

A stated aim of the process model is to execute a new process for each site to clear out the memory address space. This is similar to the design feature of SE Linux where a process execution is needed to change security context so that a clean address space is provided (preventing leaks of confidential data and attacks on process integrity). The use of multiple processes in Chrome is just begging to have SE Linux support added. Having tabs opened with different security contexts based on the contents of the site in question and also having multiple stores of cookie data and password caches labeled with different contexts is an obvious development.

Without having seen the code I can’t guess at how difficult it will be to implement such features. But I hope that when a clean code base is provided by a group of good programmers (Google has hired some really good people) then the result would be a program that is extensible.

They describe Chrome as having a sandbox based security model (as opposed to the Vista modem which is based on the Biba Integrity Model [3]).

It’s yet to be determined whether Chrome will live up to the hype (although I think that Google has a good record of delivering what they promise). But even if Chrome isn’t as good as I hope, they have set new expectations of browser features and facilities that will drive the market.

Update: Chrome is now released [4]!

Thanks to Martin for pointing out that I had misread the security section. It’s Vista not Chrome that has the three-level Biba implementation.

[1] http://googleblog.blogspot.com/2008/09/fresh-take-on-browser.html

[2] http://www.google.com/googlebooks/chrome/

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

[4] http://www.google.com/chrome

Share This

Yuichi Nakamura: [その他]makedepand

himainu — 2008-08-31T12:24:24+00:00

今更知ったコマンド。makefileの依存関係を自動的に作ってくれる。手書きでうっていた私は一体orz

KaiGai Kohei: gitメモ

KaiGai — 2008-08-29T13:46:59+00:00

CELinux Forum Japan Technical Jamboreeで、ルネサスの岩松さんから git についてのお話。

ちょうど、前の日に James Morris が俺のパッチを security-testing-2.6 ツリーの next ブランチにマージしたと言ってきたものの、リモートのリポジトリのブランチを手元に持ってくる方法がわからなかったので、これ幸いと質問。

最後のLTの時間までの間にわざわざ資料を作って教えて頂きました。多謝。
キーワードは --track で、手元のブランチが追跡すべきリモートのブランチを指定する事。これで、リモートが更新された時にも git-pull で取ってこれる。

以下は、security-testing-2.6ツリーからnextブランチを引っ張ってくる例

[kaigai@masu repo]$ git-clone git://git.kernel.org/(略)/security-testing-2.6.git
Initialized empty Git repository in /home/kaigai/repo/security-testing-2.6/.git/
remote: Counting objects: 897923, done.
remote: Compressing objects: 100% (161001/161001), done.
remote: Total 897923 (delta 749238), reused 884130 (delta 735518)
Receiving objects: 100% (897923/897923), 218.38 MiB | 2810 KiB/s, done.
Resolving deltas: 100% (749238/749238), done.
Checking out files: 100% (24333/24333), done.
[kaigai@masu repo]$ cd security-testing-2.6
[kaigai@masu security-testing-2.6]$ git-checkout --track -b next origin/next

先ずは普通に git-clone をした後、git-checkout コマンドの -b next で、新しいブランチ（名前: next）を作成する。で、このブランチは origin/next をトラッキング（--track）するという事を指定する。

これで、nextブランチのコピーを手元に持ってこれる。
無事に git-log で自分のパッチがコミットされている事を確認できた。めでたしめでたし。

commit d9250dea3f89fe808a525f08888016b495240ed4
Author: KaiGai Kohei 
Date:   Thu Aug 28 16:35:57 2008 +0900

    SELinux: add boundary support and thread context assignment

    The purpose of this patch is to assign per-thread security context
    under a constraint. It enables multi-threaded server application
    to kick a request handler with its fair security context, and
    helps some of userspace object managers to handle user's request.

KaiGai Kohei: TYPEBOUNSとマルチスレッド

KaiGai — 2008-08-29T13:31:30+00:00

SELinux: add boundary support and thread context assignment

先月から議論を続けていたパッチがカーネルにマージされた。
linux-next経由2.6.28行きという形になるだろう。
このパッチの目的は、WebサーバやAPサーバがクライアントのリクエストを処理する際に、リクエストハンドラ（例えばPHPスクリプト）をクライアントに応じた適切な権限で実行する事である。

Apacheに手を入れ、PHPスクリプトを呼び出す前にSELinuxのセキュリティコンテキストを設定すれば良いではないかと思うなかれ。スそう単純でない問題があるのである。
近頃のWeb/APサーバはマルチスレッド化で性能を稼ぐ事が多々あるが、SELinuxはスレッド単位でのドメイン付与を認めていない。１プロセス＝１ドメインなのである。

しかし、そんな事を言っていては埒が開かないのでと考えた末に出てきたアイデアが『元々のドメインに比べて、権限が完全に縮退している場合に限り、スレッド単位のドメイン遷移を認める』というものであった。

スレッドはメモリ空間を共有しており、OSが捕捉する事なく他のスレッドが読み出した情報を参照できるが、元のドメインよりも弱い権限で動いている限り、当該メモリ空間に存在してはならない情報がドメインの内部に入ってくる事はない。

上の図は、各ドメインの権限をベン図で示したもの。
httpd_php_tドメインは、完全にhttpd_tドメインに包含されており、この場合 httpd_t → httpd_php_t への遷移は可能。一方、httpd_perl_tドメインはhttpd_tに無い権限を持っているため、ドメイン遷移は認められない。

このドメイン間の強弱関係を規定するのが、新しくポリシー構文に追加した TYPEBOUNDS 文である。

書式：
  TYPEBOUNDS <境界ドメイン> <被制約ドメイン> [, <被制約ドメイン> ... ] ;
例：
  TYPEBOUNDS httpd_t httpd_php_t ;

この一文を追加する事で、httpd_php_tドメインの権限は、決してhttpd_tドメインを越える事は無くなる。無理やりパーミッションを与えても、実行時にマスクされるので無駄。

で、スレッドにドメインを設定する際には、既存のlibselinuxのAPIである setcon() を利用するが、この時、呼出しプロセスがマルチスレッド化されている場合、『新しいドメインが、元のドメインを境界ドメインとして持つ』事がドメイン遷移の条件になる。

これを使う事で、Web/APサーバがユーザのリクエストを処理する際に、ユーザに応じた適切な権限を割り当てる事が可能になる。

大仰に言えば、SELinuxがWeb Application Flawの悪夢に対して処方箋となるための第一歩。技術の普及という点でも、今まで全く関係の無かったWeb2.0の人たちとの接点を作ると言うのは大きい。
SELinuxの普及にはキラーアプリケーションが必要だとかねがね言ってきたが、Webとの連携はブレークスルーとなり得るか。今後の展開を乞うご期待。

James Morris: Linux Plumbers Conference

2008-08-29T06:14:24+00:00

I'll be attending the Linux Plumbers Conference in Portland OR a few weeks from now. It seems like a really useful event for developers, and even a little unusual in that Linus will be giving a git tutorial.

If there's anyone attending who'd like to meet up & discuss SELinux, especially distro integration issues and similar, let me know. Kees Cook from the Ubuntu project will be there, so if we have enough people, it might also be worth organizing a BoF session (it seems there are currently slots available).

Similarly, if anyone is interested in discussing the integration of MAC security with KVM (i.e. sVirt -- a project I'll discuss in more detail soon), also let me know.

Yuichi Nakamura: [組込み] CELF Jamboree 22

himainu — 2008-08-29T03:50:18+00:00

今日は大雨の影響か、人が少ない。ちょっとオタワの様子を報告してきた。午後はKaiGaiさんの話がある。前にいるKaiGaiさんと話した。 TODOは、今こそSELinux入門！コンパイルを早くするにはどうすればいいのかという話題が興味深かった。VMWare上でやるなら、単純にVMWare toolsを入れるだけでも早くなるというのは、発見だった。VMWare toolsはスルーしてたので。その他、分散コンパイルとか、分散コンパイルのためにLive CD作っちゃえとか、色々あるんだなぁ

Andrey Markelov (SELinux): Новый "Мастер" в system-config-selinux

Andrey Markelov (noreply@blogger.com) — 2008-08-28T15:16:01+00:00

Ден Уолш рассказал о добавлении в утилиту system-config-selinux мастера Boolean Lockdown Wizard. Он позволяет включать/выключать/сбрасывать в значение по умолчанию переключатели SELinux (booleans). Самое приятное отличие этого мастера от пункта Boolean в system-config-selinux - это возможность на финальном шаге через GUI сохранить текущее значение переключателей в файл.

Когда поддержка сформированных таким образом файлов будет добавлена в IPA, системный администратор сможет централизованно применять соответствующие настройки ко всем или части машин на предприятии.

Пока же можно воспользоваться командой:

[root@f9 ~]# semanage boolean -m -F my_boolean_file.txt

Обновленный пакет находится в репозитории updates-testing. Чтобы попробовать работу с новым мастером, нужно включить этот репозиторий.

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. Reposted

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:48: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.

Update: I’ve written some more about this topic in a later post [8].

[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/

[8] http://etbe.coker.com.au/2008/09/04/opinions-facts-apparmor/

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/