Planet SELinux

Dan Walsh: Why I love Open Source... II

dwalsh@redhat.com — 2012-02-03T17:23:11+00:00

When SELinux does a full relabel, it prints a * for each 1000 files that it relabels.

Some users were complaining about a full relabel and not being able to estimate how much time was left.

I explained to them that I did not know how many files were on the file system, so I could not estimate how much time was left. They explained to me that there was ways to look at the file system and get then number of inodes, and then you could estimate how much time was left. I told them patches accepted, and within a couple of days, I got a patch from John Reiser.

As of policycoreutils-2.1.10-21.fc17

If you do a touch /.autorelabel; reboot or a fixfiles restore

You will see output like

# fixfiles restore
10%

With the counter slowly rising.

Open source opens the possibility for all of us to contribute and make the whole better.

Thanks John.

Dan Walsh: 10 things you probably did not know about SELinux, #10 shipping policy versions

dwalsh@redhat.com — 2012-02-02T15:14:21+00:00

Can I install a policy module built on RHEL6 on a RHEL5 box?

First you need to understand policy is compiled statically. Even if you use interfaces, all the rules are compiled into the policy.pp file.
If you use policy_module(mypol, 1.0), this will generate a gen_require(` ') block for all of the permissions, classes defined in policy.
Meaning if you compile a policy on RHEL6 and install it on RHEL5 using policy_module(mypol,1.0) you are likely to fail with an error like:

# semodule -i mypol.pp
libsepol.permission_copy_callback: Module mypol depends on permission open in class file, not satisfied
libsemanage.semanage_link_sandbox: Link packages failed semodule: Failed!

This is the compiler telling you that you tried to install a policy module that required the "open" permission and RHEL5 policy, and kernel for that matter, has no idea what the "open" permission is.

I guess the analogy would be compiling an executable on RHEL6 that uses a function call in a shared library that does not exists on a RHEL5 box, it won't work.

Usually we recommend that you compile policy on the oldest machines policy that you plan on supporting, then it should be installable on all future versions of that policy. We don't tend to remove accesses.

Can I install a policy module built on RHEL5 on a RHEL6 box?

Yes you can, but it probably will not work the way you expect!

In RHEL5 the access required to read a file was:

define(`read_file_perms',`{ getattr read ioctl lock }')

In RHEL6 the access required to read a file was:

define(`read_file_perms',`{ open getattr read ioctl lock }')

So if you compile in a line like:

allow httpd_t mysecret_t:file read_file_perms;

On RHEL5 this would allow the apache type to read files labeled mysecret_t, but if you compiled it on RHEL5 and installed it on RHEL6, apache would not be allowed to "open" the file so the access would fail.

Bottom Line:

If you want to ship policy for two MAJOR DIFFERENT VERSIONS of RHEL then you would need to compile a version for RHEL5 and for RHEL6.

Policy should work for all Minor versions, as long as you compile on the oldest, supported version, although it might work if you compile on a newer version and install on an older version.

Meaning a compiled version of policy on RHEL6.1 should work on RHEL6.2, RHEL6.3 ...

Dan Walsh: More on deny_ptrace ...

dwalsh@redhat.com — 2012-02-01T15:03:43+00:00

This boolean brings into conflict two of my top goals with SELinux.

1. Make the system secure by default.

The problem with most security systems is NO ONE turns them on. NO ONE increases the security of their system.
Now while these are exaggerations, I would bet you that 99 % of SELinux users never turn on confined users, or disable the unconfined module . There are large numbers of people who run SELinux in permissive mode or even disabled. If we shipped Fedora and RHEL with SELinux disabled, I would bet the number of people who would enable it would be infinitesimally small. So when I add a feature, I always think about how it would help the vast majority of people. Will this boolean make my Wife's computer more secure.

2. Keep the unconfined domain unconfined...

Read the blog for why uses expect things to just work, especially from their logged in accounts, especially if they are the admin.

Should deny_ptrace be on by default????

Well deny_ptrace actually confines the unconfined domain, so it conflicts with #2, but if I don't turn it on, for the most part people will not take advantage. Most users would not see the benefit. Right now I am going to turn it on by default (Of course I reserve the right to change my mind, or be beaten into submission.) Any person who wants to disable it permanently can execute.

# setsebool -P deny_ptrace 0

Programmers and system admins if you get a "permission denied" or "Operation not supported" error with ptrace, strace or gdb, it is SELinux causing the problem, and if you need to debug a problem, you can turn the boolean on temporarily.

# setsebool deny_ptrace 0

And do your thing.

Since sysadmins and programmers understand Linux best, it would be easier for them to toggle the security feature.

Now some questions about this feature.

What happened to allow_ptrace boolean in RHEL versions and older Fedora's?

I originally thought about extending allow_ptrace, but I thought I had better just create a new boolean and remove the old.

allow_ptrace only effected confined users. But since hardly anyone used confined users, I thought I needed a better way to describe the feature, and change its name. I have removed allow_ptrace and now deny_ptrace will remove all ptrace, sys_ptrace that I know about from the system.

Does deny_ptrace guarantee no domains on my system can ptrace another domain?

NO
If you load a custom policy with an "allow XYZ self:process ptrace", this boolean will not effect it. So it only effects actually policy shipped by Fedora or Red Hat.
deny_ptrace does not effect permissive domains, or permissive mode (obviously), so if you want to make sure no processes can execute ptrace, you need to disable permissive domains.

After you turn on the deny_ptrace boolean, you can check if any domains are still able to ptrace by executing

# sesearch -A -C -p ptrace,sys_ptrace | grep -v ^D

What about separation between root and users?

Well SELinux does not know anything about UID users, so root and non root mean nothing to SELinux. The only way to get this distinction is by setting up confined users and then say run as staff_t as non root and then transition to unconfined_t, or sysadm_t or a confined admin type. But since hardly anyone uses confined users, this is not an option, if I want to make most computers more secure.

Could you add a bunch of booleans that allows us to turn on and off ptrace per confined domain?

Well this is not really necessary, since most confined domains can not ptrace now, or only could ptrace because of some bugs in the kernel that generated ptrace avc's when running the ps command as root or if a process examined the /proc/PID files of another process. We have fixed these kernel issues and are removing most domains ability to ptrace permanently, Ie turning deny_ptrace off DOES not allow every domain the ability to ptrace, only a few select domains that we believe might need it. (Really just user domains.)

Dan Walsh: Fedora 17 New SELinux Feature part I - deny_ptrace

dwalsh@redhat.com — 2012-01-31T18:43:57+00:00

The deny_ptrace feature allows an administrator to toggle the ability of processes on the computer system from examining other processes on the system, including user processes. It can even block processes running as root.

Most people do not realize that any program they run can examine the memory of any other process run by them. Meaning the computer game you are running on your desktop can watch everything going on in Firefox or a programs like pwsafe or kinit or other program that attempts to hide passwords..

SELinux defines this access as ptrace and sys_ptrace. These accesses allow one process to read the memory of another process. ptrace allows developers and administrators to debug how a process is running using tools like strace, ptrace and gdb. You can even use gdb (GNU Debugger) to manipulate another process running memory and environment.

The problem is this is allowed by default.

My wife does not debug programs, why is she allowed to debug them? As a matter of fact most of the time, I am not debugging applications, so it would be more secure if we could disable it by default.

I created a feature for Fedora 17 called SELinuxDenyPtrace

Here is a youtube video demonstrating the SELinuxDenyPtrace feature.

Check it out.

Russell Coker (security): SE Linux Status in Debian 2012-01

etbe — 2012-01-25T11:36:31+00:00

Since my last SE Linux in Debian status report [1] there have been some significant changes.

Policy

Last year I reported that the policy wasn’t very usable, on the 18th of January I uploaded version 2:2.20110726-2 of the policy packages that fixes many bugs. The policy should now be usable by most people for desktop operations and as a server. Part of the delay was that I wanted to include support for systemd, but as my work on systemd proceeded slowly and others didn’t contribute policy I could use I gave up and just released it. Systemd is still a priority for me and I plan to use it on all my systems when Wheezy is released.

Kernel

Some time between Debian kernel 3.0.0-2 and 3.1.0-1 support for an upstream change to the security module configuration was incorporated. Instead of using selinux=1 on the kernel command line to enable SE Linux support the kernel option is security=selinux. This change allows people to boot with security=tomoyo or security=apparmor if they wish. No support for Smack though.

As the kernel silently ignores command line parameters that it doesn’t understand so there is no harm in having both selinux=1 and security=selinux on both older and newer kernels. So version 0.5.0 of selinux-basics now adds both kernel command-line options to GRUB configuration when selinux-activate is run. Also when the package is upgraded it will search for selinux=1 in the GRUB configuration and if it’s there it will add security=selinux. This will give users the functionality that they expect, systems which have SE Linux activated will keep running SE Linux after a kernel upgrade or downgrade! Prior to updating selinux-basics systems running Debian/Unstable won’t work with SE Linux.

As an aside the postinst file for selinux-basics was last changed in 2006 (thanks Erich Schubert). This package is part of the new design of SE Linux in Debian and some bits of it haven’t needed to be changed for 6 years! SE Linux isn’t a new thing, it’s been in production for a long time.

Audit

While the audit daemon isn’t strictly a part of SE Linux (each can be used without the other) it seems that most of the time they are used together (in Debian at least). I have prepared a NMU of the new upstream version of audit and uploaded it to delayed/7. I want to get everything related to SE Linux up to date or at least with comparable versions to Fedora. Also I sent some of the Debian patches for the auditd upstream which should reduce the maintenance effort in future.

Libraries

There have been some NMUs of libraries that are part of SE Linux. Due to a combination of having confidence in the people doing the NMUs and not having much spare time I have let them go through without review. I’m sure that I will notice soon enough if they don’t work, my test systems exercise enough SE Linux functionality that it would be difficult to break things without me noticing.

Play Machine

I am now preparing a new SE Linux “Play Machine” running Debian/Unstable. I wore my Play Machine shirt at LCA so I’ve got to get one going again soon. This is a good exercise of the strict features of SE Linux policy, I’ve found some bugs which need to be fixed. Running Play Machines really helps improve the overall quality of SE Linux.

[1] http://etbe.coker.com.au/2011/10/31/selinux-status-2011-10/

Status of SE Linux in Debian LCA 2009 This morning I gave a talk at the Security mini-conf...
SE Linux in Debian I have now got a Debian Xen domU running the...
Debian SE Linux Status At the moment I’ve got more time to work on...

KaiGai Kohei: [OSS/Linux] PG-Stromにプロファイラをつけてみた

kaigai — 2012-01-19T06:45:53+00:00

1月6日(金)に書いた『しゅとろ〜む、しゅとろ〜む』の記事は割と反響が大きかったようだ。

コメント欄に次のような質問を頂いたので、試してみることにする。

通りすがりさん wrote:

すばらしい成果ですね．

カラム指向的にデータを持っていること自体が性能向上に寄与しているということはないですか？

(通常 + CPU) vs (カラム指向+GPU)で比較をされていますが，

(通常 + CPU) vs (カラム指向+CPU) vs (カラム指向+GPU) の評価にも興味があります．

plan.c 内の is_device_executable_qual() 関数が常に false を返すようにすれば、条件句の処理をCPUだけで行うようになる。これは (カラム指向+CPU) と同等である。

1,000万件のレコードを持つ、通常のテーブル t1 と、PG-Strom管理下のテーブル t2 に対してそれぞれ以下のクエリを実行してみた。

■ １回目（バッファにデータが乗っていない状態）

(通常 + CPU)
Timing is on.
postgres=# SELECT COUNT(*) FROM t1 WHERE sqrt((x-25.6)^2 + (y-12.8)^2) < 15;
 count
-------
  6718
(1 row)

Time: 8041.237 ms

(カラム指向 + CPU)
postgres=# SELECT COUNT(*) FROM t2 WHERE sqrt((x-25.6)^2 + (y-12.8)^2) < 15;
 count
-------
  6718
(1 row)

Time: 8660.486 ms

(カラム指向 + GPU)
postgres=# SELECT COUNT(*) FROM t2 WHERE sqrt((x-25.6)^2 + (y-12.8)^2) < 15;
 count
-------
  6718
(1 row)

Time: 4667.643 ms

■ ２回目（バッファにデータが乗っている状態）

(通常 + CPU)
postgres=# SELECT COUNT(*) FROM t1 WHERE sqrt((x-25.6)^2 + (y-12.8)^2) < 15;
 count
-------
  6718
(1 row)

Time: 7016.732 ms

(カラム指向 + CPU)
postgres=# SELECT COUNT(*) FROM t2 WHERE sqrt((x-25.6)^2 + (y-12.8)^2) < 15;
 count
-------
  6718
(1 row)

Time: 6733.771 ms

(カラム指向 + GPU)
postgres=# SELECT COUNT(*) FROM t2 WHERE sqrt((x-25.6)^2 + (y-12.8)^2) < 15;
 count
-------
  6718
(1 row)

Time: 173.351 ms

(通常+CPU)と(カラム指向+CPU)の比較で、ディスクからの読み出しが発生する場合にカラム指向の方が8%程度遅いという結果になっている。

複雑な条件句を設定したために、I/OよりもCPUバウンドな処理になっている事、xとyにはランダムな値を入れているために、全く圧縮が効いていないのが一因かもしれない。

(カラム指向 + GPU)で２回目の方が早くなっているのは、主にGPUコードのJITコンパイルの処理時間の違いによるものだろう。JITコンパイルにここまで時間がかかることは稀だが、確実にI/Oを発生させるために Linux の Page Cache をクリアしてから測定を行ったため、nvccコマンドもOSのキャッシュから弾き出されたという事だろう。

ただ、psql の \timing ではトータルの実行時間を表示するだけで、何が要因で時間を食っているのかは分からない。PG-Stromは性能改善を目的とするモジュールなので、どの辺を改善したら良いのか探るには先ず、どの辺にボトルネックがあるのかを探る必要がある。

という訳で、PG-StromのGUCパラメータ pg_strom.exec_profile を追加してみた。

これに "on" をセットすると、各々コンポーネントで消費した時間を表示してくれる。

postgres=# SET pg_strom.exec_profile = ON;
SET

（カラム指向 + GPU; １回目）

postgres=# SELECT COUNT(*) FROM t2 WHERE sqrt((x-25.6)^2 + (y-12.8)^2) < 15;
INFO:  PG-Strom Exec Profile on "t2"
INFO:  Total PG-Strom consumed time: 4367.067 ms
INFO:  Time to JIT Compile GPU code: 1741.505 ms
INFO:  Time to initialize devices:   345.353 ms
INFO:  Time to Load column-stores:   2119.669 ms
INFO:  Time to Scan column-stores:   3.566 ms
INFO:  Time to Fetch virtual tuples: 110.920 ms
INFO:  Time of GPU Synchronization:  31.244 ms
INFO:  Time of Async memcpy:         31.320 ms
INFO:  Time of Async kernel exec:    27.906 ms
INFO:  Num of registers/thread [0]:  25
INFO:  Constant memory usage [0]:    40 byte
INFO:  Max device memory usage[0]:   536 KB
 count
-------
  6718
(1 row)

Time: 4514.738 ms

\timing で計測した応答時間 4514.738ms のうち、PG-Strom モジュール内の処理時間は 4367.067 msで、そのうち、大部分を占めるのが、GPUコードのJITコンパイル（1741.505ms）と、カラムストアからのロード（2119.669ms）になる。これと比べると、GPUでの処理時間・メモリ転送は桁が違う。

（カラム指向 + GPU; ２回目）

postgres=# SELECT COUNT(*) FROM t2 WHERE sqrt((x-25.6)^2 + (y-12.8)^2) < 15;
INFO:  PG-Strom Exec Profile on "t2"
INFO:  Total PG-Strom consumed time: 183.302 ms
INFO:  Time to JIT Compile GPU code: 0.043 ms
INFO:  Time to initialize devices:   1.134 ms
INFO:  Time to Load column-stores:   54.883 ms
INFO:  Time to Scan column-stores:   3.425 ms
INFO:  Time to Fetch virtual tuples: 96.384 ms
INFO:  Time of GPU Synchronization:  27.462 ms
INFO:  Time of Async memcpy:         30.737 ms
INFO:  Time of Async kernel exec:    27.906 ms
INFO:  Num of registers/thread [0]:  25
INFO:  Constant memory usage [0]:    40 byte
INFO:  Max device memory usage[0]:   536 KB
 count
-------
  6718
(1 row)

Time: 186.867 ms

１回目で時間を食っていた、GPUコードのJITコンパイル処理時間が消え、カラムストアからのロード時間も大幅に減っている。また、地味にデバイスの初期化にも345.353 ms要していたが、これがほぼ無くなっている。

この結果、トータルの処理時間が4514.738 ms⇒186.867msに減少。

カラムストアのロード/スキャンと、タプルをフェッチする処理（これはFDWの仕様なので減らすのが難しい）、それにGPUの処理の同期で合わせて 182.154 ms が消費されている。

1/6(金)の時点から少しアルゴリズムを変更しているが、メモリ使用量はほとんど問題になっていない。

これは、I/O周りで時間がかかっているために、２個、３個とチャンクを非同期に処理しようとしても、次のチャンクを読み込んでGPUに渡す頃には、前のチャンクの処理が既に終わっているからという事だろう。

この辺、もっと足回りの良いマシンなら変わってくるのだろうか。

なお、Time to scan... というのは、条件句を評価した結果に基づいてカラムストアをスキャンする処理で、条件句には使われていないものの、Target-listに含まれるカラムが存在する場合に発生する。今回のクエリは COUNT(*) を返すだけなので、追加のスキャンは発生していない。

おまけ。(カラム指向 + CPU)の実行結果だとこうなる。

postgres=# SELECT COUNT(*) FROM t2 WHERE sqrt((x-25.6)^2 + (y-12.8)^2) < 15;
INFO:  PG-Strom Exec Profile on "t2"
INFO:  Total PG-Strom consumed time: 2314.374 ms
INFO:  Time to JIT Compile GPU code: 0.000 ms
INFO:  Time to initialize devices:   0.000 ms
INFO:  Time to Load column-stores:   6.881 ms
INFO:  Time to Scan column-stores:   1435.570 ms
INFO:  Time to Fetch virtual tuples: 871.891 ms
INFO:  Time of GPU Synchronization:  0.000 ms
INFO:  Time of Async memcpy:         0.000 ms
INFO:  Time of Async kernel exec:    0.000 ms
 count
-------
  6718
(1 row)

Time: 8063.461 ms

トータル 8063ms のうち、PS-Strom内の処理は 2314 ms。つまり、必死こいてPG-Stromから本体側にメモリコピーの後、CPUで条件句を処理という流れが見える。PG-Strom内での結果の絞込みができないので、Fetch virtual tuplesの時間が大幅に増加しているのが分かる。

それと、Scan column-store の時間もやや気がかり。足回りとして、この辺は改善の余地があるやも。

James Morris: Save the date: 2012 Linux Security Summit, 30-31 August, San Diego

jamesm — 2012-01-18T00:43:18+00:00

This is a pre-announcement so people can start planning travel for the year.

The Linux Security Summit for 2012 will be held on the 30th and 31st of August in San Diego, CA, USA. It will be co-located with LinuxCon North America, plumbers and the kernel summit.

More details to follow.

James Morris: New git repository for the Linux kernel security subsystem

jamesm — 2012-01-16T05:02:20+00:00

I’ve set up a new git repository for the Linux kernel security subsystem on the new kernel.org server.

The URLs are:

git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git
http://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git
https://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git

Developers should work against the “next” branch.

A web-browsable interface via gitweb may be found at:

http://git.kernel.org/?p=linux/kernel/git/jmorris/linux-security.git;a=summary

The temporary repo on selinuxproject.org will go away soon, so please update your repositories.

KaiGai Kohei: [OSS/Linux]PG-Strom

kaigai — 2012-01-09T20:07:30+00:00

I've checked up an idea whether it is feasible to implement, or not, since I saw a presentation by Tim Child in Ottawa last year.

Is it possible to accelerate sequential-scan of PostgreSQL?

We often see sequential-scan instead of index-scan in case of queries with complex calculation. I thought GPU works fine in these cases.

I tried to implement a module that works as FDW (foreign data wrapper) of PostgreSQL, since I could have a time to develop during Christmas vacation.

The name of module is PG-Strom that is pronounced as shutt-row-me; being pronounced in German style.

Its name originates "Streaming Multiprocessor" that is a unit of process in GPU.

Of course, it assumes existing interface of FDW, so it is unavailable to update, and some more restrictions like sort or aggregate functions. However, it achieves good performance as a prototype.

Note that the following description is based on author's understanding (quite newbie for CUDA), so please point out if something incorrect.

Benchmark

Even though it is an arbitrary testcase, I tries to execute a query that scans a table with 20-million records in my development environment. NVidia's GTS450eco is installed.

-- A regular table
mytest=# SELECT count(*) FROM pgbench_accounts
    WHERE (xval - 23.45) * (xval - 23.45) + (yval - 54.32) * (yval - 54.32) < 100;
 count
--------
 629291
(1 row)

Time: 29030.738 ms

-- with PG-Strom
mytest=# SELECT count(*) FROM pgstrom_accounts
    WHERE (xval - 23.45) * (xval - 23.45) + (yval - 54.32) * (yval - 54.32) < 100;
 count
--------
 629291
(1 row)

Time: 2337.475 ms

It is a surprising result. PG-Strom returns the result with 10 times faster!

In addition, we may be able to expect more improvement because GPU is quite cheap one (about 100Euro).

Let's try again. I reduced the number of records (5-million records, with shared_buffer=960MB) to store whole of the table on the buffer; to eliminate affects from disk-I/O.

-- A regular table
mytest=# SELECT count(*) FROM t1
   WHERE (xval - 23.45) * (xval - 23.45) + (yval - 54.32) * (yval - 54.32) < 100;
 count
--------
 157800
(1 row)

Time: 4106.045 ms

-- with PG-Strom
mytest=# SELECT count(*) FROM t2
    WHERE (xval - 23.45) * (xval - 23.45) + (yval - 54.32) * (yval - 54.32) < 100;
 count
--------
 157800
(1 row)

Time: 393.346 ms

Wow!

Idea

PostgreSQL iterates (1) fetch a tuple from storage (or buffer), and (2) evaluation of qualifier of WHERE clause according to contents of the tuple during sequential-scan. Thus, it unavailable to handle (2) during execution of (1), and also unavailable to handle (1) during execution of (2). An idea is CPU multi-threading, however, it is hard to implement because PostgreSQL does not have thread-safe design including memory or I/O management.

PG-Strom entrusts GPU device the (2) portion (evaluation of WHERE clause), and make CPU focus on I/O stuff.

The calculation stuff shall be handled on GPU device side asynchronously, so it shall be finished during CPU handles more I/O stuff.

However, GPU is not a magic bullet for anything.

We need to transfer data to be calculated by GPU into device memory mounted on GPU. It requires to transfer via PCI-E that has narrow bandwidth compared to the one between CPU and Memory. (Max 2.5GB/s in x16 lane)

Thus, amount of data to be copied should be smaller as we can as possible.

In most cases, it is rare case that WHERE clause reference all the columns within the table, because the purpose of query is to fetch a record that satisfies the condition of XXXXX.

PG-Strom handles execution of WHERE clause on GPU device. At that time, all copied to GPU device are contents of referenced columns. I expect 10%-20% of table size needs to be copied to GPU device via PCI-E, because numeric data is smaller than text data.

Data structure and Asynchronous process

The internal data structure of PG-Strom is organized according to the above idea.

For example, when we create a foreign table with four-columns: a, b, c and d, PG-Strom creates tables corresponding to each columns within pg_strom schema. These tables have rowid (int64) to identify a particular row and an array-type to store multiple original data.

Even though it is a column-oriented data structure recently well used, it does not go out of transaction management of PostgreSQL, PG-Strom does not need to touch them.

This type of data structure allows PG-Strom to load data into GPU devices via PCI-E bus effectively.

The contents read from the databases are temporarily stored on fixed-length buffer called "chunk", then it shall be moved to GPU devices and calculated, and the results shall be written back at last. These steps are executed asynchronously, thus, CPU can scan the database concurrently to set up next chunk. This design enables to utilize both of CPU and GPU.

Just-in-time compile and native-code execution

CPU and GPU have its own advantage and disadvantage for each. GPU has much higher computing capability using large number of calculation units in parallel, however, one of its disadvantage is conditional branch.

NVidia's GPU synchronously run 32 of execution units (that is called as SM:Streaming-Multiprocessor) like as a SIMD operations. In the case when device code contains conditional-branch part, a particular thread has 'true' on the condition, and other thread has 'false' on the condition, then, all the threads execute both of true-block and false-block and result of the block to be skipped shall be ignored. Thus, we cannot ignore the cost to execute branch statement within GPU device, especially, if-block is big.

PostgreSQL has internal representation of WHERE clause as tree-structure, and we scan the tree-structure using switch statement on execute them. It shall be worst effectiveness.

Thus, PG-Strom adopts Just-in-time compile to generate native binary code of GPU to avoid execution control on GPU device.

When the supplied query tries to reference a foreign-table managed by PG-Strom, the query planner requires PG-Strom to generate execution plan. At that time, PG-Strom dynamically generate a source code towards GPU device, then kicks nvcc (compiler of NVidia's device) to build a native code of GPU device.

Of course, it shall be cached on shared memory to avoid execute compiler so frequently.

Next, when query-executor calls PG-Strom's executor, as I mentioned above, this native code shall be transferred to the device side with data read from pg_strom schema, and executed asynchronously.

The qualifiers of WHERE clause is already extracted on the planner stage, no need to handle a big switch statement.

We can confirm the automatically generated code of GPU device.

mytest=# EXPLAIN SELECT * FROM pgstrom_accounts
         WHERE (xval - 23.45) * (xval - 23.45) +
               (yval - 54.32) * (yval - 54.32) < 100;
                        QUERY PLAN
--------------------------------------------------------------
 Foreign Scan on pgstrom_accounts  (cost=2.00..0.00 rows=1000 width=368)
    Required Cols : aid, bid, abalance, filler, xval, yval
   Used in clause : xval, yval
      1: typedef unsigned long size_t;
      2: typedef long __clock_t;
      3: typedef __clock_t clock_t;
      4: #include "crt/device_runtime.h"
      5:
      6: typedef char  bool_t;
      7:
      8: __global__ void
      9: pgstrom_qual(unsigned char rowmap[],
     10:              double c5_values[],
     11:              unsigned char c5_nulls[],
     12:              double c6_values[],
     13:              unsigned char c6_nulls[])
     14: {
     15:     int offset_base = blockIdx.x * blockDim.x + threadIdx.x;
     16:     int offset = offset_base * 8;
     17:     unsigned char result = rowmap[offset_base];
     18:     unsigned char errors = 0;
     19:     unsigned char cn5 = c5_nulls[offset_base];
     20:     unsigned char cn6 = c6_nulls[offset_base];
     21:     int bitmask;
     22:
     23:     for (bitmask=1; bitmask < 256; bitmask <<= 1)
     24:     {
     25:         double cv5 = c5_values[offset];
     26:         double cv6 = c6_values[offset];
     27:
     28:         if ((result & bitmask) &&
                    !((((cv5 - 23.45) * (cv5 - 23.45)) +
                       ((cv6 - 54.32) * (cv6 - 54.32))) < 100))
     29:             result &= ~bitmask;
     30:         offset++;
     31:     }
     32:     rowmap[offset_base] = (result & ~errors);
     33: }
(36 rows)

Publication

Right now, it is in public at GitHub. GPLv3 is applied.

https://github.com/kaigai/pg_strom

Even though it is a prototype, thus, its specification depends on my feeling, and we cannot expect documentation for a while, if you'd like to use, please call me (@kkaigai) on twitter.

A short demonstration

This is a short demonstration. The 't1' table is a regular table with 5-million records, and the 't2' table is a foreign table managed by PG-Strom also with 5-million records.

In the case of sequential-scan with complex qualifier, scan on 't2' was finished x10 times faster than the case of 't1'.

KaiGai Kohei: [OSS/Linux] しゅとろ〜む、しゅとろ〜む

kaigai — 2012-01-06T12:15:00+00:00

昨年、オタワでTim Child氏の発表を聞いて以来、実装できないものかと思って暖めていたアイデアがある。GPUの処理能力を使って、PostgreSQLの検索処理を高速化できないか？というものである。

特に複雑な計算を含むクエリの場合、Index-Scanに落ちないで、全件スキャンが走ることが往々にしてあるが、こういったケースで有効に作用するのではなかろうか？という着想である。

クリスマス休暇の間、割とまとまった開発時間を取る事ができたので、PostgreSQLのFDW(Foreign Data Wrapper)として動作するモジュールを作成してみた。

モジュールの名前は PG-Strom で、ドイツ風に『しゅとろ〜む』と発音する。

これは GPU の処理単位である Streaming Multiprocessor に由来する。

もちろん、現状のFDWのI/F前提なので、更新は不可能でソートや集約関数もモジュール側に出せないという諸々制約はあるが、プロトタイプとしてはまずまずの性能である。

※ なお、下記のGPU関連の記述は著者（CUDAプログラミング歴１ヶ月）の理解によるものです。間違っていたらご指摘ください。むしろ教えてくださいｗ

ベンチマーク

かなり恣意的なテストケースではあるが、2,000万件のレコードからなるテーブルを全件スキャンするクエリを手元の環境で実施してみた。なお、搭載しているGPUはNvidia GTX450ecoである。

-- 従来のテーブル
mytest=# SELECT count(*) FROM pgbench_accounts
    WHERE (xval - 23.45) * (xval - 23.45) + (yval - 54.32) * (yval - 54.32) < 100;
 count
--------
 629291
(1 row)

Time: 29030.738 ms

-- PG-Stromを利用
mytest=# SELECT count(*) FROM pgstrom_accounts
    WHERE (xval - 23.45) * (xval - 23.45) + (yval - 54.32) * (yval - 54.32) < 100;
 count
--------
 629291
(1 row)

Time: 2337.475 ms

驚いた事に、1/10以下の応答時間でクエリを実行してしまったではないか。

しかも利用しているGPUは100Euro程度のショボイものだけに、伸びしろもあるだろう。

もう一回、今度はディスクIOの影響を除くため、テーブル全体がバッファに乗るサイズ（shared_buffer=960MBで、件数を500万件に削減）で試してみた。

-- 従来のテーブル
mytest=# SELECT count(*) FROM t1
   WHERE (xval - 23.45) * (xval - 23.45) + (yval - 54.32) * (yval - 54.32) < 100;
 count
--------
 157800
(1 row)

Time: 4106.045 ms

mytest=# SELECT count(*) FROM t2
    WHERE (xval - 23.45) * (xval - 23.45) + (yval - 54.32) * (yval - 54.32) < 100;
 count
--------
 157800
(1 row)

Time: 393.346 ms

わお！

アイデア

PostgreSQLの場合、基本的に全件スキャン時の処理は (1) ディスク(or バッファ)からの読み出し (2) タプルの内容に基づいて WHERE 条件句を評価の繰り返しとなる。

そのため、(1)の処理中は(2)を実行できず、(2)の処理中は(1)を実行できない。CPUマルチスレッド化はひとつのアイデアだが、PostgreSQLはメモリ管理やI/O周りを含めて Thread-Safe な構造にはなっていないため、これは非常に難しい。

PG-Stromでは、(2)のWHERE条件句の処理を GPU 側に任せる事で、CPUをI/Oに専念させる。

計算処理はGPU側で非同期に実施してくれるので、CPUから見た場合『ここにあるデータを評価しておいて頂戴』と頼んでおくと、しばらくI/O処理をしている間に計算結果が出来上がっている、という算段である。

ただ、GPUに処理をさせれば万事OKかというと、そうは問屋が卸さない。

GPUで計算させるには、GPU搭載のdevice memoryにデータを転送する必要があるが、これには PCI-Eを通して転送する必要があり、この箇所の帯域はCPU-Memory間に比べて非常に小さいのである。(x16のバスでもMAX片側2.5GB/s)

したがって、GPUデバイスに転送するデータの量はできるだけ少なくした方がよい。

通常、SQLのWHERE条件句がテーブルの全てのカラムを参照するという事は考えにくい。

『○○の条件を満たすレコードを取り出す』というのがクエリの目的だからだ。

PG-StromではWHERE条件句の処理をGPU側で実行するが、その際、GPUデバイス側に転送されるのは計算に必要なカラムだけである。普通は数値データの方が文字列よりも短いため、PCI-Eを介してGPUデバイスに転送の必要があるのは、テーブル全体の10%-20%程度ではなかろうか。

データ構造と非同期処理

PG-Stromの内部データ構造も、上記の方針に従って編成されている。

例えば、a、b、c、dの4つのカラムを持つFOREIGN TABLEを定義したとき、PG-Stromは各々のカラムに対応するテーブルを"pg_strom"スキーマ内に作成する。これらのテーブルは、行を一意に識別する rowid (int64) と、元々のデータを配列化したデータ型を持つ事になる。

最近流行のカラム指向DB的なデータ構造という訳だが、あくまでも PostgreSQL のトランザクション管理の枠内でデータ構造を規定しているので、その辺の厄介な処理は PG-Strom の側では一切ノータッチで済ませている。

この様なデータ構造を持つ事により、PG-StromではPCI-Eを介してGPUデバイスに送り込むデータを高速にDBから読み込めるようになっている。読み込んだデータはチャンクと呼ぶ固定長のバッファに蓄えられ、順次GPUデバイスに送出、GPUでの演算処理を行い、結果の書き戻しが行われる。

実際にはこれらの一連の処理は全て非同期に実施されるため、CPUはその間もDBからデータを読み込み、次のチャンクのセットアップが可能であるため、CPU/GPUを効率的に利用する事ができる。

Just-in-time compile と native code 実行

CPUとGPUにはそれぞれ得意不得意の分野があり、GPUは非常に多くの並列演算ユニットを協調して動作させる事により高い計算能力を発揮するが、不得意な分野もある。その一つが条件分岐である。

NVidiaのGPUでは32個の実行ユニットを含むStreaming Multiprocessorという単位で、SIMDライクな処理が行われる。GPU内の処理が条件分岐を含み、特定のスレッドでは IF 条件が真に、別のスレッドでは偽になるような場合、全てのスレッドがIF文の真ブロック/偽ブロックを処理し、IF条件に合致しないケースを破棄するという処理が行われる。そのため、特にIFブロックのサイズが大きくなるに従って、GPU内で条件句を処理する際のコストが無視できないものとなる。

PostgreSQL内部ではWHERE条件句をツリー状のデータ構造によって保持しているが、ツリーを順にスキャンして『次は '+' 演算子だから…』と switch() 文で分岐させるような処理は、最悪の効率、という事になる。

※ ただ、並列に実行する全てのスレッドでIF条件の評価結果が同じ場合にどうなるか？という点は、調べた限りではよく分からなかった。この場合にペナルティが避けられるのであれば、GPU側でコントロール処理を行うのも一つのアイデア。

そのため、PG-StromではJust-in-time compileの技術を使って動的にネイティブのGPUコードを生成して実行するという方針を採用している。

利用者のクエリがPG-Strom管理下の外部テーブルを参照する場合、Query PlannerはPG-Stromに対してクエリ実行プランを作成するよう要求する。その時、PG-Strom PlannerはWHERE条件句に従って動的にGPUデバイス用のコードを生成し、nvcc（NVidia の GPU向けコンパイラ）を実行してGPU向けのネイティブコードを生成する。もちろん、毎回コンパイラを起動していては時間の無駄なので、生成したバイナリは共有メモリ上にキャッシュされる。

次いで、Query-ExecutorがPG-Strom Executorを呼び出すと、前述の通り、pg_stromスキーマ内から読み出したデータと共に、GPU向けのネイティブコードがデバイス側に送出され、非同期に実行される。

WHERE条件句は既にPlanner段階で展開されているので、改めて巨大な switch 文を処理する必要は…ない。

ちなみに、EXPLAIN文でどのようなGPU向けのコードが生成されているかを見る事ができる。

mytest=# EXPLAIN SELECT * FROM pgstrom_accounts
         WHERE (xval - 23.45) * (xval - 23.45) +
               (yval - 54.32) * (yval - 54.32) < 100;
                        QUERY PLAN
--------------------------------------------------------------
 Foreign Scan on pgstrom_accounts  (cost=2.00..0.00 rows=1000 width=368)
    Required Cols : aid, bid, abalance, filler, xval, yval
   Used in clause : xval, yval
      1: typedef unsigned long size_t;
      2: typedef long __clock_t;
      3: typedef __clock_t clock_t;
      4: #include "crt/device_runtime.h"
      5:
      6: typedef char  bool_t;
      7:
      8: __global__ void
      9: pgstrom_qual(unsigned char rowmap[],
     10:              double c5_values[],
     11:              unsigned char c5_nulls[],
     12:              double c6_values[],
     13:              unsigned char c6_nulls[])
     14: {
     15:     int offset_base = blockIdx.x * blockDim.x + threadIdx.x;
     16:     int offset = offset_base * 8;
     17:     unsigned char result = rowmap[offset_base];
     18:     unsigned char errors = 0;
     19:     unsigned char cn5 = c5_nulls[offset_base];
     20:     unsigned char cn6 = c6_nulls[offset_base];
     21:     int bitmask;
     22:
     23:     for (bitmask=1; bitmask < 256; bitmask <<= 1)
     24:     {
     25:         double cv5 = c5_values[offset];
     26:         double cv6 = c6_values[offset];
     27:
     28:         if ((result & bitmask) &&
                    !((((cv5 - 23.45) * (cv5 - 23.45)) +
                       ((cv6 - 54.32) * (cv6 - 54.32))) < 100))
     29:             result &= ~bitmask;
     30:         offset++;
     31:     }
     32:     rowmap[offset_base] = (result & ~errors);
     33: }
(36 rows)

公開先

今のところGitHUBで公開中。ライセンスはGPLv3です。

https://github.com/kaigai/pg_strom

まだプロトタイプ段階なので、私の気分次第で仕様は変わりますし、当面はドキュメントも期待できません。それでも使ってみようという奇特な方がいらっしゃいましたら、Twitter (@kkaigai) などで呼びかけてもらえれば。

Russell Coker (security): My Blog Server was Cracked

etbe — 2011-12-31T00:01:06+00:00

On the 1st of August I noticed that the server which runs my blog among other things was having an occasional SEGV from a sshd process. Unfortunately I was busy and didn’t pay much attention to this, which turned out to be a big mistake.

On the 12th of September I started investigating this properly and noticed that when someone tried to connect to ssh with password authentication sshd would SEGV after it was denied access to a shared memory region or a semaphore which had a SE Linux type of unconfined_t. I added some SE Linux auditallow rules and discovered that the memory region in question was created by the ssh client. Shortly after that I came to the conclusion that this wasn’t some strange feature of ssh (or one of the many shared objects it uses) but hostile activity. The ssh client appeared to be storing passwords that it used in a shared memory region and sshd was also collecting passwords in the same region and presumably offering them to a ssh client which uses some extension to the ssh protocol.

The sshd process was crashing because it couldn’t handle EPERM on access to shared memory or semaphores. Presumably if the system in question wasn’t running SE Linux then the exploit would have remained undetected for a lot longer.

At this stage we don’t know how the attacker got in. Presumably one of the people with root access ran a ssh client on a compromised system and had their password sniffed. One such client system was mysteriously reinstalled at about that time, the sysadmin of the system in question claimed to have no backups which made it impossible to determine if that system had been compromised. I believe that the sysadmin of the client system knew that their system was compromised, kept that information secret, and allowed other systems to become and remain compromised.

The attacker made no good effort to conceal their presence, they replaced ssh, sshd, and ssh-add and didn’t bother changing the Debian checksums so the debsums program flagged the files as modified. Note that I have kept copies of the files in question and am willing to share them with anyone who wants to analyse them.

Steinar H. Gunderson has named this trojan Ebury [1].

Recovery

By the evening of the 13th of September I had the system mostly working again. Jabber still isn’t working because ejabberd is difficult to get working at the best of times, I am now investigating whether there is a better Jabber server to use, but as I don’t use Jabber often this hasn’t been a priority for me.

Some of the WordPress plugins I use and all of the WordPress themes that are installed were outside the Debian packaging system, as I couldn’t be sure that they hadn’t been altered (because the people who wrote WordPress plugins don’t keep old versions online) I had to upgrade to the newer versions. Of course the newer versions weren’t entirely compatible so I had to use a different theme and I couldn’t get all plugins working. Link Within no longer works, not that it ever worked properly [2], I wanted to try Outbrain again but their web site won’t let me login (and they haven’t responded to my support request). Does anyone know of a good WordPress plugin to provide links to related content? Either related content on my blog or on the Internet in general will be OK.

Some people have asked me about the change in appearance of my blog. It was simply impossible (for someone with my PHP skills) to get my blog looking the same way as it did before the server was cracked. I think that the new look is OK and don’t mind if people think it looks likw a VW advert – VW make great cars, I was very satisfied with the VW Passat I used to drive.

Future Plans

I had bought some Yubikeys (USB devices that generate one-time passwords) [3] to control access to that server, if I had configured the software to use them then this might not have happened. The use of one-time password devices can prevent passive password-sniffing attacks. It would still allow active attacks (such as using ControlPath/ControlMaster options on the ssh client to allow a hostile party to connect later (EG the -M, -S, and “-o ControlPersist” options for the ssh client). It’s a pity that there doesn’t seem to be a way to configure the ssh server to disable ControlMaster.

Conclusion

It would be good to have some changes to sshd to allow more restrictions on what a client can request, as ControlMaster functionality isn’t needed by most users it should be possible to disable it.

SE Linux doesn’t protect against a compromised client system or any other way of stealing passwords. It did do a good job of stopping Ebury from doing all the things it wanted to do and thus making me aware of the problem. So I count this as a win for SE Linux.

Yubikeys are the cheapest and easiest way of managine one-time passwords. I had already bought some for use on the system in question but hadn’t got around to configuring them. I have to make that a priority.

Email Passwords I was doing some routine sysadmin work for a client...
Case Sensitivity and Published Passwords When I first started running a SE Linux Play Machine...
what’s a good blog server for serious blogging? I’m getting sick of blogger. The main thing is that...

Russell Coker (security): Secure Boot and Protecting Against Root

etbe — 2011-12-28T04:16:22+00:00

There has been a lot of discussion recently about the recent Microsoft ideas regarding secure boot, in case you have missed it Michael Casadevall has written a good summary of the issue [1].

Recently I’ve seen a couple of people advocate the concept of secure boot with the stated idea that “root” should be unable to damage the system, as Microsoft Software is something that doesn’t matter to me I’ll restrict my comments to how this might work on Linux.

Restricting the “root” account is something that is technically possible, for much of the past 9 years I have been running SE Linux “Play Machines” which have UID 0 (root) restricted by SE Linux such that they can’t damage the system [2] – there are other ways of achieving similar goals. But having an account with UID 0 that can’t change anything on the system doesn’t really match what most people think of as “root”, I just do it as a way of demonstrating that SE Linux controls all access such that cracking a daemon which runs as root won’t result in immediately controlling the entire system.

As an aside my Play Machine is not online at the moment, I hope to have it running again soon.

Root Can’t Damage the System

One specific claim was that “root” should be unable to damage the system. While a secure boot system can theoretically result in a boot to single user mode without any compromise that doesn’t apply to fully operational systems. For a file owned by root to be replaced the system security has to be compromised in some way. The same compromise will usually work every time until the bug is fixed and the software is upgraded. So the process of cracking root that might be used to install hostile files can also be used at runtime to exploit running processes via ptrace and do other bad stuff.

Even if the attacker is forced to compromise the system at every boot this isn’t a great win for the case of servers with months of uptime or for the case of workstations that have confidential data that can be rapidly copied over the Internet. There are also many workstations that are live on the Internet for months nowadays.

Also the general claim doesn’t really make sense on it’s own. “root” usually means the account that is used for configuring the system. If a system can be configured then the account which is used to configure it will be able to do unwanted things. It is theoretically possible to run workstations without external root access (EG have them automatically update to the latest security fixes). Such a workstation configuration MIGHT be able to survive a compromise by having a reboot trigger an automatic update. But a workstation that is used in such a manner could be just re-imaged as it would probably be used in an environment where data-less operation makes sense.

An Android phone could be considered as an example of a Linux system for which the “root” user can’t damage the system if you consider “root” to mean “person accessing the GUI configuration system”. But then it wouldn’t be difficult to create a configuration program for a regular Linux system that allows the user to change some parts of the system configuration while making others unavailable. Besides there are many ways in which the Android configuration GUI permits the user to make the system mostly unusable (EG by disabling data access) or extremely expensive to operate (EG by forcing data roaming). So I don’t think that Android is a good example of “root” being prevented from doing damage.

Signing All Files

Another idea that I saw advocated was to have the “secure boot” concept extended to all files. So you have a boot loader that loads a signed kernel which then loads only signed executables and then every interpreter (Perl, Python, etc) will also check for signatures on files that they run. This would be tricky with interpreters that are designed to run from standard input (most notably /bin/sh but also many other interpreters).

Doing this would require changing many programs, I guess you would even have to change mount to check the signature on /etc/fstab etc. This would be an unreasonably large amount of work.

Another possibility would be to change the kernel such that it checks file signatures and has restrictions on system calls such as open() and the exec() family of calls. In concept it would be possible to extend SE Linux or any other access control system to include access checks on which files need to be signed (some types such as etc_t and bin_t would need to be signed but others such as var_t wouldn’t).

Of course this would mean that no sysadmin work could be performed locally as all file changes would have to come from the signing system. I can imagine all sorts of theoretically interesting but practically useless ways of implementing this such as having the signing system disconnected from the Internet with USB flash devices used for one-way file transfer – because you can’t have the signing system available to the same attacks as the host system.

The requirement to sign all files would reduce the use of such a system to a tiny fraction of the user-base. Which would then raise the question of why anyone would spend the effort on that task when there are so many other ways of improving security that involve less work and can be used by more people.

Encrypted Root Filesystem

One real benefit of a secure boot system is for systems using encrypted filesystems. It would be good to know that a hostile party hasn’t replaced the kernel and initrd when you are asked for the password to unlock the root filesystem. This would be good for the case where a laptop is left in a hotel room or other place where a hostile party could access it.

Another way of addressing the same problem is to boot from a USB device so that you can keep a small USB boot device with you when it’s inconvenient to carry a large laptop (which works for me). Of course it’s theoretically possible for the system BIOS to be replaced with something that trojans the boot process (EG runs the kernel in a virtual machine). But I expect that if someone who is capable of doing that gets access to my laptop then I’m going to lose anyway.

Conclusion

The secure boot concept does seem to have some useful potential when the aim is to reboot the system and have it automatically apply security fixes in the early stages of the boot process. This could be used for Netbooks and phones. Of course such a process would have to reset some configuration settings to safe defaults, this means replacing files in /etc and some configuration files in the user’s home directory. So such a reboot and upgrade procedure would either leave the possibility that files in /etc were still compromised or it would remove some configuration work and thus give the user an incentive to avoid applying the patch.

Any system that tries to extend signature checks all the way would either be vulnerable to valid but hostile changes to system configuration (such as authenticating to a server run by a hostile party) or have extreme ease of use issues due to signing everything.

Also a secure boot will only protect a vulnerable system between the time it is rebooted and the time it returns to full operation after the reboot. If the security flaw hasn’t been fixed (which could be due to a 0-day exploit or an exploit for which the patch hasn’t been applied) then the system could be cracked again.

I don’t think that a secure boot process offers real benefits to many users.

Question about a “Secure Filesystem” I have just been asked for advice about “secure filesystem”...
How SE Linux Prevents Local Root Exploits In a comment on my previous post about SE Linux...
Logging in as Root Martin Meredith wrote a blog post about logging in as...

Dan Walsh: 10 things you probably did not know about SELinux #9 Backing up and Restoring Labels.

dwalsh@redhat.com — 2011-12-12T19:38:21+00:00

It has been a few years since I discusses backing up and restoring labels with SELinux.

I was asked at the Lisa 11 conference by a backup utility developer, "How should he save and restore SELinux security contexts?" He also asked whether or not his tool should always maintain these context? Finally how should the tool react if the system would not allow the context to be restored?

Interesting topic. Lets first take a look at a few tools for backing up content with SELinux labels.

SELinux stores SELinux security labels (contexts) as extended attributes with the inode on the file system. If an administrate wants to backup/restore files with the SELinux labels, you need to use a utility that supports this.

When SELinux first shipped the only utility to do this was star (RHEL4) , GNU tar at that time did not support extended attributes. Later extended attribute support was added to GNU tar. ( tar --selinux -cvf /tmp/etc.tgz /etc ) Rsync also has support for maintaining extended attributes. Even Dump/Restore can now support maintaining the extended attributes.

I often question is whether this is a good idea to maintain the labels. In some cases your security goals require it. For example backing up sensitivity labelled data (MLS) requires this. If you have a file labelled TopSecret, you would definitely want to maintain this within the archive.

But most of us do not deal with sensitivity labelled data, and we would want to make sure the data on our system is labelled correctly based on the current security definition on our system. Trying to maintain the SELinux labels and restore them can be a mistake in several cases.

For example:

Target file system does not support extended attributes.

If you attempted to restore files to a file system that does not support extended attributes. Does the administrator have a way to allow this?

Updating a machine for one version of the OS to another.

If you backed up your /home directory before updating from Fedora 15 to Fedora 16 and then restored the content of the archive, certain directories in you home directory will be mislabeled and potentially tools like googlechrome or colord will fail. You would have been better off having the content restored the archive and then running restorecon -R - v /home.

Copying an archive from one machine to another machine with an older OS.

Attempting to maintain the labels would be wrong if you created an archive on a RHEL6 box and then attempting to restore the archive on a RHEL5 box. If the RHEL5 kernel does not understand a label from a RHEL6 box, then the label will not be allowed to be placed on the disk. In this case, again you would want to put the files down and then restore the labels.

In this case it would be nice if the tools used to restore the content had the ability to label the content "correctly" based on the file_contexts definitions on the target system. That way we would not have a race condition where the labels on the files are incorrect for a period of time.

In conclusion the backup/restore utility should:

allow the administrator to decide whether or not to save the SELinux labels and restore them.
Allow the administrator to specify the tool to restore the files using the default labels as specified on the target system (matchpathcon/setfscreatecon)
If the utility does not allow have the second option, in most cases the administrator should run restorecon on the restored files.

Dan Walsh: Why isn't setroubleshoot working in Fedora 16?

dwalsh@redhat.com — 2011-12-08T18:13:21+00:00

Well if you did a fresh install it does work. But if you did an upgrade install from an older Fedora you have a problem.

setroubleshootd is a dbus service launched by the audit daemon. In Fedora 16 all daemons that were running under as System V init scripts and were converted to systemd, no longer are started by default. Meaning the auditd daemon is probably no longer running on your machines. You might notice AVC messages showing up in /var/log/messages, rather then /var/log/audit/audit.log.

It is simple to fix this problem by executing

# systemctl enable auditd.service
# systemctl start auditd.service

This will re-enable the auditd daemon and your setroubleshoot daemon should start working again. If you get any AVC messages, they will start showing up in the /var/log/audit/audit.log.

KaiGai Kohei: [OSS/Linux]Leaky Views と Security Barrier : PostgreSQL Advent Calendar #4

kaigai — 2011-12-03T15:37:23+00:00

このエントリはPostgreSQL Advent Calendarに参加しています。12/4(日)担当也。ヨーロッパ中部時間ではまだ12/3(土)ですが。

RDBMSで行レベルのアクセス制御を実現する方法として、利用者に対して直接のアクセス権を付与せずに、特定のビューを通してだけアクセスを許可するのはしばしば使われるテクニックです。

ですが、場合によっては不可視な行の中身を参照できてしまうというのは、あまり広く認知されている訳ではないようです。

ので、問題のポイントと、現在開発中の PostgreSQL v9.2 に提案しているアイデアをご紹介します。

ユーザ定義関数のCOST値による問題

ここでは、以下の表を例に考えてみます。

customerテーブル

列名	型	制約
cid	int	primary key
cname	text	not null
cmail	text
cpasswd	text

customerテーブルには全顧客の情報が格納されているため、利用者は自分自身の情報しか見る事ができないよう設定しましょう。

（便宜上 PostgreSQL ユーザ名が cname に対応するものとします）

postgres=# CREATE VIEW my_account AS SELECT * FROM customer
                  WHERE cname = getpgusername();
CREATE VIEW
postgres=# GRANT SELECT ON my_account TO public;
GRANT

本来、このテーブルには 3ユーザ分の情報が格納されているのですが、

postgres=# SELECT * FROM customer;
 cid | cname |       cmail       | cpasswd
-----+-------+-------------------+----------
 101 | alice | alice@example.com | abcdef
 102 | bob   | bob@example.com   | xyz123
 103 | eve   | eve@example.com   | deadbeaf
(3 rows)

確かに、自分自身の情報しか参照できないように見えます。

postgres=# SET SESSION AUTHORIZATION alice;
SET
postgres=> SELECT * FROM customer;
ERROR:  permission denied for relation customer
postgres=> SELECT * FROM my_account;
 cid | cname |       cmail       | cpasswd
-----+-------+-------------------+---------
 101 | alice | alice@example.com | abcdef
(1 row)

しかし、利用者がSQL関数を定義できる場合、面白い事が起こります。

（publicスキーマはデフォルトでCREATE権限を全体に与えている事に注意！）

postgres=> CREATE FUNCTION f_leak(text) RETURNS bool LANGUAGE plpgsql
           COST 0.00000001
           AS 'BEGIN RAISE NOTICE ''f_leak => %'', $1; RETURN true; END';
CREATE FUNCTION

postgres=> SELECT * FROM my_account WHERE f_leak(cmail);
NOTICE:  f_leak => alice@example.com
NOTICE:  f_leak => bob@example.com
NOTICE:  f_leak => eve@example.com
 cid | cname |       cmail       | cpasswd
-----+-------+-------------------+---------
 101 | alice | alice@example.com | abcdef
(1 row)

おっと、何か見えてはならないモノが見えたようです。

どういう事なのでしょうか、ちょっと EXPLAIN で調べてみましょう。

postgres=> EXPLAIN SELECT * FROM my_account WHERE f_leak(cmail);
                           QUERY PLAN
-----------------------------------------------------------------
 Seq Scan on customer  (cost=0.00..20.85 rows=1 width=100)
   Filter: (f_leak(cmail) AND (cname = (getpgusername())::text))
(2 rows)

この実行計画はVIEWの本体である customer テーブルをスキャンしていますが、利用者が付与した f_leak() とVIEWの条件を順にチェックしています。

問題は、副作用を持つ f_leak() の実行コストが非常に小さな値に設定されているため、オプティマイザは cname = getpgusername() より先にf_leak()を実行して不必要な条件の判断を省略した方が得策であると判断して、関数の実行順序を並べ替えている事です。その結果、不可視であるべき行の内容が引数としてf_leak()に渡され、それが利用者に漏えいしている訳です。

JOINと条件句の分配に伴う問題

同様に、VIEWによる行レベルアクセス制御を破るシナリオはもう一つ知られています。

先ほどの customer テーブルに加えて、もう一つテーブルを追加して考察を進めてみましょう。

creditテーブル

列名	型	制約
cid	int	references customer(cid)
number	text
expired	date

この credit テーブルは顧客のクレジットカード番号を保持しています。先ほどの my_account ビューと同様に、自分自身のレコードだけを参照できるようなVIEWを定義してみましょう。

postgres=# SELECT * FROM customer;
 cid | cname |       cmail       | cpasswd
-----+-------+-------------------+----------
 101 | alice | alice@example.com | abcdef
 102 | bob   | bob@example.com   | xyz123
 103 | eve   | eve@example.com   | deadbeaf
(3 rows)

postgres=# SELECT * FROM credit;
 cid |       number        |  expired
-----+---------------------+------------
 101 | 1111-2222-3333-4444 | 2014-02-28
 102 | 5555-6666-7777-8888 | 2013-10-30
 102 | 1234-5678-1234-5678 | 2015-06-30
 103 | 0987-6543-2109-8765 | 2014-08-31
(4 rows)

postgres=# CREATE VIEW my_credit AS SELECT cname, cmail, credit.*
           FROM customer NATURAL JOIN credit WHERE cname = getpgusername();
CREATE VIEW
postgres=# GRANT SELECT ON my_credit TO public;
GRANT

おや、やっぱり何かおかしいようです。

postgres=# SET SESSION AUTHORIZATION alice;
SET
postgres=> SELECT * FROM my_credit;
 cname |       cmail       | cid |       number        |  expired
-------+-------------------+-----+---------------------+------------
 alice | alice@example.com | 101 | 1111-2222-3333-4444 | 2014-02-28
(1 row)

postgres=> SELECT * FROM my_credit WHERE f_leak(number);
NOTICE:  f_leak => 1111-2222-3333-4444
NOTICE:  f_leak => 5555-6666-7777-8888
NOTICE:  f_leak => 1234-5678-1234-5678
NOTICE:  f_leak => 0987-6543-2109-8765
 cname |       cmail       | cid |       number        |  expired
-------+-------------------+-----+---------------------+------------
 alice | alice@example.com | 101 | 1111-2222-3333-4444 | 2014-02-28
(1 row)

もう一度 EXPLAIN で実行計画を眺めてみましょう。

postgres=> EXPLAIN SELECT * FROM my_credit WHERE f_leak(number);
                              QUERY PLAN
----------------------------------------------------------------------
 Hash Join  (cost=20.89..43.96 rows=2 width=104)
   Hash Cond: (credit.cid = customer.cid)
   ->  Seq Scan on credit  (cost=0.00..21.60 rows=387 width=40)
         Filter: f_leak(number)
   ->  Hash  (cost=20.85..20.85 rows=3 width=68)
         ->  Seq Scan on customer  (cost=0.00..20.85 rows=3 width=68)
               Filter: (cname = (getpgusername())::text)
(7 rows)

困ったことに、『creditテーブルをf_leak()条件でスキャンした結果』と『customerテーブルをcname = getpgusername()条件でスキャンした結果』がJOINされています。

オプティマイザはJOINすべき行を最小化するよう条件句を分配するのですが、f_leak()関数は credit テーブルの number 列のみ、cname = getpgusername() 条件は customer テーブルの cname 列のみに依存しています。そのため、JOINの完了を待つ事なく個々のテーブルをスキャンする時点で条件句を実行した方が、JOINすべき行数を減らす事ができます。

その結果、副作用を持つf_leak()がcreditテーブルのスキャン計画に push-down され、最初の例と同様に、不可視であるべき行の内容がf_leak()に渡され、それが利用者に漏えいしてしまっています。

この２つの問題は共に、オプティマイザがVIEWの境界を越えて関数の実行順序を入れ替えている事が原因です。これは性能観点からは優れた実装ですが、セキュリティを目的としたVIEW定義という観点では問題です。

一方で、VIEW内部で使われている関数を全て評価してから、その外部から与えられた関数を評価するという実装は、安全ですが、性能上無視できない性能劣化をもたらします。例えば、1万行 x 1万行のテーブルをJOINする場合、外部から与えられた関数をテーブルスキャンの時点で評価する事で片方の行数を1万行から100行に絞り込めるとしたら、9900万行分のJOIN処理を省略する事ができます。

次に、PostgreSQL v9.2に向けて提案されている Leaky View 問題への対策を紹介しましょう。

VIEW の security_barrier 属性と最適化の抑制

ここからは、私の提案している「Fix Leaky View Problemパッチ」の解説です。

前節で考察したように、VIEWを行レベルアクセス制御の目的で利用する場合には、パフォーマンスとセキュリティのトレードオフが存在します。安全側に倒せば許容できない程の性能劣化を招く可能性があり、一方、性能最適であれば情報漏えいの危険があります。

Fix Leaky Views Problem パッチは、CREATE VIEW構文でWITH(...)句を用いてオプション値を指定することを許容します。構文は以下の通りです。

CREATE VIEW view_name [WITH (options[,...])] AS select_statement;
options:
  security_barrier[= true|false]

security_barrier オプションは、VIEWが行レベルアクセス制御を目的として定義されていることを示す属性です。これを指定することで、一部のクエリ最適化を抑制する事が可能になります。

この設計に至るまでには長い議論があったのですが、結局、パフォーマンスとセキュリティのどちらが重要であるのかを判断できるのはVIEWを定義する人のみである、というシンプルな結論にたどり着いたのでした。

VIEWにsecurity_barrier属性が付与されている時、VIEWの内側で使用されている全ての関数・条件句は、VIEWの外側から与えられた関数・条件句よりも先に実行される事が保証されます。

では、実際に試してみましょう。以下で定義する my_account_secure と my_credit_secure は、先ほどの2つの例で使用したVIEWにsecurity_barrier属性を付加したものです。

postgres=# CREATE VIEW my_credit_secure WITH (security_barrier) AS
           SELECT cname, cmail, credit.* FROM customer NATURAL JOIN credit
           WHERE cname = getpgusername();
CREATE VIEW
postgres=# GRANT SELECT ON my_account_secure TO public;
GRANT
postgres=# CREATE VIEW my_account_secure WITH (security_barrier) AS
           SELECT * FROM customer WHERE cname = getpgusername();
CREATE VIEW
postgres=# GRANT SELECT ON my_credit_secure TO public;
GRANT

動作結果は以下のようになりました。"f_leak => ..." と表示されている内容は、クエリによって本来参照可能なデータの範囲内に収まっている事が分かります。

postgres=# SET SESSION AUTHORIZATION alice;
SET
postgres=> SELECT * FROM my_account_secure WHERE f_leak(cmail);
NOTICE:  f_leak => alice@example.com
 cid | cname |       cmail       | cpasswd
-----+-------+-------------------+---------
 101 | alice | alice@example.com | abcdef
(1 row)

postgres=> SELECT * FROM my_credit_secure WHERE f_leak(number);
NOTICE:  f_leak => 1111-2222-3333-4444
 cname |       cmail       | cid |       number        |  expired
-------+-------------------+-----+---------------------+------------
 alice | alice@example.com | 101 | 1111-2222-3333-4444 | 2014-02-28
(1 row)

では、VIEWにsecurity_barrier属性を付加することで、クエリ実行計画にどのように変化しているのでしょうか？先ほどと同じように、EXPLAIN構文で調べてみましょう。

postgres=> EXPLAIN SELECT * FROM my_account_secure WHERE f_leak(cmail);
                               QUERY PLAN
-------------------------------------------------------------------------
 Subquery Scan on my_account_secure  (cost=0.00..20.88 rows=1 width=100)
   Filter: f_leak(my_account_secure.cmail)
   ->  Seq Scan on customer  (cost=0.00..20.85 rows=3 width=100)
         Filter: (cname = (getpgusername())::text)
(4 rows)

f_leak()関数の評価は cname = getpgusername() 条件で customer テーブルをスキャンした後に行われる事が分かります。オプティマイザは security_viwe 属性を持ったVIEWの内側に条件句を push-down しなくなりました。

もう一つの例も同様です。

postgres=> EXPLAIN SELECT * FROM my_credit_secure WHERE f_leak(cmail);
                                 QUERY PLAN
----------------------------------------------------------------------------
 Subquery Scan on my_credit_secure  (cost=20.89..46.96 rows=2 width=104)
   Filter: f_leak(my_credit_secure.cmail)
   ->  Hash Join  (cost=20.89..46.90 rows=6 width=104)
         Hash Cond: (credit.cid = customer.cid)
         ->  Seq Scan on credit  (cost=0.00..21.60 rows=1160 width=40)
         ->  Hash  (cost=20.85..20.85 rows=3 width=68)
               ->  Seq Scan on customer  (cost=0.00..20.85 rows=3 width=68)
                     Filter: (cname = (getpgusername())::text)
(8 rows)

パッチ自体の動作原理は極めて単純です。

PostgreSQLは、一旦、VIEWに対するクエリを内部的にサブクエリに書き換えます。その後、オプティマイザがクエリ実行計画を作成する際に、"シンプル"なサブクエリ（OFFSET/LIMIT句を含まない…など）であれば、性能最適の観点からサブクエリをJOINを用いてフラット化(Pull-Up)します。

その後で、条件句はオプティマイザによって性能上最適な位置に振り分けられるため、VIEWの内側/外側といった区別はもはや意味を持たなくなります。

VIEWのsecurity_barrier属性は、この際の条件に作用します。RangeTblEntry構造体のsecurity_barrierは、関連するサブクエリがVIEWに由来し、かつ、VIEWのsecurity_barrier属性がtrueである場合にセットされます。

以下の処理では、security_barrier属性が false だとpull_up_simple_subquery()は呼ばれないため、サブクエリのフラット化は抑制されます。

--- a/src/backend/optimizer/prep/prepjointree.c
+++ b/src/backend/optimizer/prep/prepjointree.c
@@ -543,6 +543,7 @@ pull_up_subqueries(PlannerInfo *root, Node *jtnode,
         */
        if (rte->rtekind == RTE_SUBQUERY &&
            is_simple_subquery(rte->subquery) &&
+           !rte->security_barrier &&
            (containing_appendrel == NULL ||
             is_safe_append_member(rte->subquery)))
            return pull_up_simple_subquery(root, jtnode, rte,

さらにもう一ヶ所。条件句に与える引数が特定のサブクエリにだけ依存している場合、オプティマイザはこの条件句の実行をサブクエリ処理の中に移動(Push-Down)しようとしますが、同様にサブクエリが security_view 属性つきのVIEWに由来する時は、これをスキップします。

@@ -763,6 +769,7 @@ set_subquery_pathlist(PlannerInfo *root, RelOptInfo *rel,
      Node       *clause = (Node *) rinfo->clause;

      if (!rinfo->pseudoconstant &&
+         !rte->security_barrier &&
          qual_is_pushdown_safe(subquery, rti, clause, differentTypes))
      {
          /* Push it down */

この２ヶ所の処理を追加することによって、これまで見たような、VIEWを行レベルアクセス制御の目的に使用する場合の問題を回避する事ができます。

FUNCTION の leakproof 属性

Leaky View問題はVIEWのsecurity_barrier属性によって解決する事ができるのですが、これは一部のクエリ最適化を無効化するために、場合によっては、そのためのコストが看過できないほど大きい事もあります。

例えば、アプリケーションの設計上、以下のようなVIEWを定義し、VIEWの外側から条件句（主キーによる絞込みなど）を与えて使いたいというケースを考えてみましょう。

CREATE VIEW valid_credit WITH (security_barrier) AS
    SELECT * FROM credit WHERE card_is_valid(number, expired);

SELECT * FROM valid_credit WHERE cid = <customer-id>;

この場合、card_is_valid関数と、VIEWの外部から与えた cid = <customer-id> を用いて credit テーブルをスキャンした結果が利用者には返されます。ですが、VIEWにはsecurity_barrier属性が設定されているため、常にcard_is_valid関数が先に実行されます。

この制限は cid 列にインデックスが設定されていても同様です。したがってインデックス・スキャンが選択されるべき状況でも全件スキャンが選択されてしまいます。ああ困った、困った。

Fix Leaky View ProblemパッチはPart-1とPart-2から構成されており、Part-1は前述の security_barrier 属性の実装を、Part-2ではその例外を設定する機能を実装しています。

Part-2によって、先ほどのオプティマイザへの変更は一部修正されます。

--- a/src/backend/optimizer/path/allpaths.c
+++ b/src/backend/optimizer/path/allpaths.c
@@ -769,7 +769,8 @@ set_subquery_pathlist(PlannerInfo *root, RelOptInfo *rel,
        Node       *clause = (Node *) rinfo->clause;

        if (!rinfo->pseudoconstant &&
-           !rte->security_barrier &&
+           (!rte->security_barrier ||
+            !contain_leakable_functions(clause)) &&
            qual_is_pushdown_safe(subquery, rti, clause, differentTypes))
        {
            /* Push it down */

サブクエリがsecurity_barrier属性付きのVIEWに由来するとき、このif文は条件句のPush-Downを抑止しますが、Part-2パッチは条件句(clause)が leakable-functions （つまり情報を漏えいする可能性のある関数）を含んでいなければ、サブクエリへの条件句のPush-Downを許可するように修正します。

では、関数が情報を漏えいする可能性の有無をどのように設定するか。

それには、CREATE FUNCTION構文に新たに追加されるLEAKPROOF属性を使用します。

例えば、以下のように使用します。LEAKPROOFを指定することで、この関数に情報漏えいの恐れがないという事を明示的に指定できますが、これは同時に、潜在的に不可視の行の内容を参照することを可能にするため、関数のLEAKPROOF属性をセットするには特権ユーザの権限が必要です。

（SE-PostgreSQLでも db_procedure:{install}権限をチェックする予定です）

CREATE FUNCTION is_positive(int) RETURNS bool LANGUAGE plpgsql
    LEAKPROOF
    AS 'BEGIN RETURN $1 > 0; END';

一部のビルトイン関数の中でも、明らかに情報漏えいのリスクがない関数については、デフォルトでLEAKPROOF属性がセットされています。

（全部で2400個程あるため、網羅的なチェックはこれからですが…。）

例えば、32bit Integer同士の大小比較を行う int4gt 関数は、以下のように実装されています。

Datum
int4gt(PG_FUNCTION_ARGS)
{
    int32       arg1 = PG_GETARG_INT32(0);
    int32       arg2 = PG_GETARG_INT32(1);

    PG_RETURN_BOOL(arg1 > arg2);
}

この実装に情報漏えいの危険はありませんので、DB初期化時にLEAKPROOF属性はセットされています。

その他にも、現在のパッチでは各種ビルトインタイプの等価・大小比較演算子の実装として利用されている関数にLEAKPROOF属性がついています。実際に試してみましょう。

postgres=# SET SESSION AUTHORIZATION bob;
SET
postgres=> SELECT * FROM my_credit;
 cname |      cmail      | cid |       number        |  expired
-------+-----------------+-----+---------------------+------------
 bob   | bob@example.com | 102 | 5555-6666-7777-8888 | 2013-10-30
 bob   | bob@example.com | 102 | 1234-5678-1234-5678 | 2015-06-30
(2 rows)

ユーザ bob は2枚のクレジットカードを持っています。リッチメンですね。

では、２つの条件句を付加してみます。一つは先ほどのf_leak()関数、もう一つは expired < '2014-01-01' という Date 型の大小比較演算です。

postgres=> SELECT * FROM my_credit_secure WHERE f_leak(number) AND expired < '2014-01-01';
NOTICE:  f_leak => 5555-6666-7777-8888
 cname |      cmail      | cid |       number        |  expired
-------+-----------------+-----+---------------------+------------
 bob   | bob@example.com | 102 | 5555-6666-7777-8888 | 2013-10-30
(1 row)

NOTICEメッセージが一行だけ表示されているという事は、大小比較演算はf_leak()関数よりも先に実行されたようです。EXPLAINで実行計画を見てみましょう。

postgres=> EXPLAIN SELECT * FROM my_credit_secure WHERE f_leak(number) AND expired < '2014-01-01';
                                QUERY PLAN
---------------------------------------------------------------------------
 Subquery Scan on my_credit_secure  (cost=1.06..27.06 rows=1 width=104)
   Filter: f_leak(my_credit_secure.number)
   ->  Hash Join  (cost=1.06..27.04 rows=2 width=104)
         Hash Cond: (credit.cid = customer.cid)
         ->  Seq Scan on credit  (cost=0.00..24.50 rows=387 width=40)
               Filter: (expired < '2014-01-01'::date)
         ->  Hash  (cost=1.05..1.05 rows=1 width=68)
               ->  Seq Scan on customer  (cost=0.00..1.05 rows=1 width=68)
                     Filter: (cname = (getpgusername())::text)
(9 rows)

見ての通り、expired < '2014-01-01' 条件句が credit テーブルのスキャンに結びついているのと比較して、f_leak()関数はmy_credit_secureビューの内側にPush-Downされていません。これが LEAKPROOF 属性の有無による違いです。もし credit テーブルにインデックスが設定されていれば、Push-Downされた条件句により、全件スキャンの代わりにインデックス・スキャンが選択されるかもしれません。

まとめ

確かこの問題は、かれこれ2年以上議論を続けてきた息の長い問題です。

2009年9月4日のセキュアOS塾『SE-PostgreSQL vs Oracle Label Security』の資料の中で言及があります。（p.34）

http://sepgsql.googlecode.com/files/090904-jsosjk04-sepgsql-vs-ols.pdf

開発コミュニティとしての方向性は、概ね上で紹介した形で収束しつつありますが、まだ v9.2 の新機能として紹介できるかどうか、は分からない状況です。が、SE-PostgreSQLの行レベルアクセス制御機能を実現するためにもマージしておきたい機能ですので、なんとかcommitできるよう頑張りたいところです。

最後に『じゃあ、既存のシステムではどうやって対策したら良いのよ？』という質問に対して一つTIPSを紹介しておきたいと思います。

Q. PostgreSQL v9.1以前のバージョンでLeaky View問題を防ぐにはどうしたらよいか？

A. クエリに OFFSET 0 を付ける

オプティマイザがサブクエリをフラット化、または、条件句をPush-Downする時、サブクエリにOFFSET/LIMIT句が含まれている場合はそれを断念する、という事を思い出してください。

OFFSET 0は結果セットの先頭から値を読むという意味ですので、本来は何の意味もありません。ですが、ここまで説明した条件句の実行順序に起因する問題を防ぐには簡便な方法です。

ただし、関数のLEAKPROOF属性に相当する機能はありませんので、その点でトレードオフは必要になります。

PostgreSQL Advent Calendar向けに記事を書くにあたり、MySQL、MS SQL Server、Oracle Databaseなど他のRDBMSの挙動はどうなっているのか調べたかったのですが、時間がありませんでした。特に Oracle は勝手にWHERE句に条件をくっつけるVirtual Private Databaseという機能を持っていますので気になります。

これらは、追って調査したいと思います。きっと。いつの日か。アディオス、アミーゴ。

さて、翌 12/5(月) は笠原さんです。よろしく〜

Dan Walsh: SELinux versus pam_securid.so

dwalsh@redhat.com — 2011-12-02T12:55:03+00:00

Seems to be my month for fighting pam modules from third parties.   I have heard that RSA corporation is recommending SELinux be turned off to run their products. I just love it when a supposed security company recommends that customers turn on a key security component of the Operating System. Now did RSA ever contact me to work through the problems,? No.

Come on RSA you can do better then this.

I am trying to avoid underhanded security comment about using SELinux to protect key assets of the company...

I worked with Joe Lucchesi, to get this pam module to work with SELinux. Joe was having problems with sshd working with the pam module. He was getting execstack errors. Turns out the pam_securid.so file was shipped with the execstack flag turned on. Execstack is a dangerous protection to allow a domain, since it turns off protection against buffer overflow attacks. Most app never need this access.

Executing

execstack -c /lib64/security/pam_securid.so

Cleared the flag. And allowed sshd to get past this AVC. Whatever is causing this flag to be set, the build procedure or installation needs to be fixed.

The next problems we hit was pam_securid seems to be running netstat under the covers. I recall we had this problem with the Netscape Certificate libraries. They used to execute netstat in order to generate entropy when using certificates, so I figure this is what is going on here. I also see the sshd executing ps? Probably for the same reason.

RSA guys please use /dev/urandom and /dev/random.

We turned off the use of netstat in our libraries years ago. Using netstat and ps causes me to have to allow login programs to search /sys/net and because of bugs in our kernel add a dontaudit for sys_ptrace.

Finally secureid uses /var/ace to store its authorization content. This should probably be under /var/lib/ace, I have added a label for this directory

/var/ace(/.*)?                 gen_context(system_u:object_r:var_auth_t,s0)

This should allow the pam_securid module to use the content in this directory.

Now Joe can run his pam_securid.so on his machine in enforcing mode with a small custom module until we push updates to fix the problem.

Bottom line. If you are a third party and you are having problems running your tools with SELinux, please, please contact me or Red Hat and lets work through the problems, and give our users a better experience.

Dan Walsh: SELinux versus pam_google_authenticator...

dwalsh@redhat.com — 2011-11-18T15:45:17+00:00

I just became aware of a new PAM, pam_google_authenticator.

It is some kind of One TIme Password tool to allow you to add One Time Passwords to you Linux Login and I guess use your Android phone.

pam_google_authenticator causes login programs to try and write to ~/.google_authenticator by default. SELinux does not like this. SELinux prevents login programs from writing to random locations in the home directory. It is usually not a good idea to rely on stuff in the home dir for authorization because the homedir may require authorization to be able to be mounted or decrypted. (kNFS for example).

I got a bugzilla on sshd not being able to write to ~/.google_authenticator. One option would be to set the label on the .google_authenticator as ssh_home_t. I also did some "googling" and found the following entry:
http://code.google.com/p/google-authenticator/wiki/PamModuleInstructions

Comment by phil.may <snip>, Jul 7, 2011

If you are using Fedora and SELinux, you will need to use the right config. The default SELinux policy does not allow the SSH daemon to update the ~/.google_authenticator file.

In Fedora 14 (and possibly other versions) sshd runs under "sshd_t" and can only writelocations with certain SELinux labels. One such label is "var_auth_t" and the default policy sets this label on "/var/run/user/" Therefore, the following config works:

# If the user is NOT in group "otp_users", skip next module
auth [success=1 default=ignore] pam_succeed_if.so user notingroup otp_users
auth       required     pam_google_authenticator.so secret=/var/run/user/${USER}/.google_authenticator
auth       include      password-auth

BTW I have not tried this out on Fedora 16, and am curious if this will work, or does pam_google_authenticator expect the contents of .google_authenticator to survive a reboot.

Dan Walsh: Customizing the Kiosk OS.

dwalsh@redhat.com — 2011-11-17T20:54:01+00:00

I receve a decent amount of interest about the kiosk spin, but I have never formalized it as a fedora spin. The reason for this is almost everyone who looks at it, likes the idea but they need to customize it, in one way or another.

My vision of the Kiosk Operating system was that it was readonly and periodically an admin would recut/rebuild a newer version and then redestribute it to his machines. It is fairly easy to build your own image. Just download the kiosk kickstart file (kiosk.ks), make some customization and rebuild your ISO file using the livecd-tools. The last step would be to install it to your favorite medium, USB Sticks or DVD.

I recently received an email that requested:

"I have downloaded kiosk just this afternoon and tried on my laptop: as I have been requested for such a spin in our city library for eight computers, how can I build a spin with language/keyboard set as Italian??? (the standard procedure to change settings/Logout/login seems not to be working..) "

Here is how I would go about building the Italian version of the Kiosk Operating System.

On the currently released version of Fedora. As I write this blog, we are at Fedora 16. Login as root and and follow this procedure.

You are going to build the Kiosk Operating System using the spin-kickstarts, so we need to install the sortware.

# yum install spin-kickstarts livecd-tools
# cd /usr/share/spin-kickstarts

Make sure you have the latest kiosk.ks file from my people page. http://people.fedoraproject.org/~dwalsh/SELinux/kiosk/kiosk.ks

# rm -f kiosk.ks*
# wget http://people.fedoraproject.org/~dwalsh/SELinux/kiosk/kiosk.ks

Change the default language within the kickstart file. You can use your favorite editor to do this, and modify "lang" line. I will just use a sed command.

# sed -i 's/en_US.UTF8/it_IT.UTF-8/g' kiosk.ks

Now you can build a new kiosk image. Replacing the name of the livecd with your own content.

# livecd-creator -t MYLIBRARY -f MYLIBRARY -c kiosk.ks --cache=/var/cache/kiosk

Now go get a cup of coffee since this will take a long while, maybe a half hour.
When it finishes, you will have an ISO image named MYLIBRARY.iso. You need to install the iso ont a dvd or to a usb stick using livecd-iso-to-disk.

# livecd-iso-to-disk --totaltimeout 1 ./MYLIBRARY.iso /dev/sdb1

Remove your USB stick and attempt a boot a machine using it.

Of course if you want to add some less then free packages to your kiosk operating system, you would edit the kickstart file and add your alternative repositories.

For additional information on building livecd please use:

http://fedoraproject.org/wiki/How_to_create_and_use_Live_USB

And on using kickstart files.

http://fedoraproject.org/wiki/Anaconda/Kickstart

Russell Coker (security): SE Linux Status in Debian 2011-10

etbe — 2011-10-31T12:22:43+00:00

Debian/Unstable Development

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

The above APT sources.list line has my repository for SE Linux packages that have been uploaded to Unstable and which will eventually go to testing and then the Wheezy release (if they aren’t obsoleted first). I have created that repository for people who want to track SE Linux development without waiting for an Unstable mirror to update.

In that repository I’ve included a new version of policycoreutils that now includes mcstrans and also has support for newer policy such that the latest selinux-policy-default package can be installed. The version that is currently in Testing supports upgrading policy on a running system but doesn’t support installing the policy on a system that previously didn’t run SE Linux.

I have also uploaded SE Linux Policy packages from upstream release 20110726 compared to the previous packages which were from upstream release 20100524. As the numbers imply there is 14 months of upstream policy development which changes many things. Many of the patches from my Squeeze policy packages are not yet incorporated in the policy I have uploaded to Unstable. I won’t guarantee that an Unstable system in Enforcing mode will do anything other than boot up and allow you to login via ssh. It’s definitely not ready for production but it’s also very suitable for development (10 years ago I did a lot of development on SE Linux systems that often denied login access, it wasn’t fun).

Kyle Moffett submitted a patch for libselinux which dramatically changed the build process. As Manoj (who wrote the previous build scripts) was not contactable I accepted Kyle’s patch as provided. Thanks for the patch Kyle, and thanks for all your work over the years Manoj. Anyway the result of these changes should mean that it’s easier to bootstrap Debian on a new architecture and easier to support multi-arch – but I haven’t tested either of these.

Squeeze

The policy packages from Squeeze can’t be compiled on Unstable. The newer policy compilation tool chain is more strict about how some things can be declared and used, thus some policy which was fairly dubious but usable is now invalid. While it wouldn’t be difficult to fix those problems I don’t plan to do so. There is no good reason for compiling Squeeze policy on Unstable now that I’ve uploaded a new upstream release.

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

I am still developing Squeeze policy and releasing it in the above APT repository. I will also get another policy release in a Squeeze update if possible to smooth the transition to Wheezy – the goal is that Squeeze policy will be usable on Wheezy even if it can’t be compiled. Also note that the compilation failures only affect the Debian package, it should still be possible to make modules for local use on a Wheezy system with Squeeze policy.

MLS

On Wednesday I’m giving a lecture at my local LUG about MLS on SE Linux. I hope to have a MLS demonstration system available to LUG members by then. Ideally I will have a MLS system running on a virtual server somewhere that’s accessible as well as a Xen/KVM image on a USB stick that can be copied by anyone at the meeting.

I don’t expect to spend much time on any aspect of SE Linux unrelated to MLS for the rest of the week.

Version Control

I need to change the way that I develop SE Linux packages, particularly the refpolicy source package (source of selinux-policy-default among others). A 20,000 line single patch is difficult to work with! I will have to switch to using quilt, once I get it working well it should save me time on my own development as well as making it easier to send patches upstream. Also I need to setup a public version control system so I can access the source from my workstation, laptop, and netbook. While doing that I might as well make it public so any interested people can help out. Suggestions on what type of VCS to use are welcome.

How You Can Help

Sorting out the mess that is the refpolicy package, sending patches upstream and migrating to a VCS is a fair bit of work. But there are lots of small parts. Sending patches upstream is a job that could be done in small pieces.

Writing new policy is not something to do yet. There’s not much point in doing that while I still haven’t merged all the patches from Squeeze – maybe next week. However I can provide the missing patches to anyone who wants to review them and assist with the merging.

I have a virtual server that has some spare capacity. One thing I would like to do is to have some virtual machines running Unstable with various configurations of server software. Then we could track Unstable on those images and use automated testing to ensure that nothing breaks. If anyone wants root access on a virtual server to install their favorite software then let me know. But such software needs to be maintained and tested!

Debian SSH and SE Linux I have just filed Debian bug report #556644 against the...
/run and SE Linux Policy Currently Debian/Unstable is going through a transition to using /run...
SE Linux status in Debian/Squeeze ffmpeg I’ve updated my SE Linux repository for Squeeze to...

Russell Coker (security): Capabilities vs SE Linux

etbe — 2011-10-28T02:47:57+00:00

In December 2010 a paper was published by Robert N.M. Watson and Jonathan Anderson from the Cambridge University and Ben Laurie and Kris Kennaway of Google about the Capsicum capabilities system [1]. It seems that the aim of the project is to allow systems that need privileges briefly when they start (such as tcpdump) a safe method of dropping privs. The main project page is here [2].

The focus of the paper is on the Chromium web browser and six different ways of constraining the Chromium sandbox are compared. For the SE Linux comparison they claim 200 lines of code changes as of Fedora 15, in Fedora 16 I couldn’t find a Chromium package, so I presume that they mean 200 lines of SE Linux policy (I am not aware of anyone modifying the Chromium source for SE Linux). They note that SE Linux doesn’t support separating different sandboxes, while it would be possible to have each sandbox be assigned a different MCS sensitivity label to separate them that option would be unwieldy enough that they are essentially correct in this regard. For SE Linux systems running the MLS policy the correct thing to do would be to run multiple copies of Chromium at different levels to access different sensitivity levels of data, this would normally be done by polyinstantiating the home directory.

One thing to note however is that there is no requirement that only one security method be implemented. I can’t think of any technical reason why it would be impossible to run SE Linux and Capsicum on the same system. SE Linux could constrain daemons and restrict the access to Capsicum services while Capsicum could be used to give minimum privileges to parts of Chromium. I’m not sure that such a combination would offer anything that the MLS users would desire, but it seems that everyone else (the vast majority of computer users) would be served well by a combination of SE Linux and Capsicum.

It’s disappointing that the paper didn’t mention Posix 1003.1e capabilities, but given the lack of use that Posix capabilities get that’s understandable.

It’s also disappointing when someone develops something new and different nowadays and doesn’t provide a virtual machine image for it. Installing and configuring something that requires application and kernel changes is a lot of work and most people who are idly curious about the technology won’t go to the effort. By today’s standards it’s not that difficult to share a 1GB filesystem image via Bittorrent.

SE Linux vs chroot A question that is often asked is whether to use...
Creating a SE Linux Chroot environment Why use a Chroot environment? A large part of the...
Context of /dev/xvc0 I have just converted a Fedora Core 5 server to...

Dan Walsh: Open Source how do I love thee, let me count the ways.

dwalsh@redhat.com — 2011-10-25T12:37:05+00:00

Yesterday I got contacted by Red Hat Support about a problem we had in libselinux. If you are setting up confined users you can use the semanage login command to setup a group of linux users to be assigned to a confined user type.

# semanage login -a -s staff_u -r s0-s0:c0.c1023 %wheel

This command would cause all linux users in the wheel group to login as the staff_u SELinux user. Well we had a bug in getseuserbyname function in libseliunux. When you login to a system the pam_selinux module uses this function to figure out which SELinux user should be used for your UID. There was a bug where we were not allocating enough memory for reading the entire group file contents. Basically if the number of users within a group was too large, the library would stop reading.

A customer of ours found the problem and reported it.

Now the reason I love Open Source...

The customer did not stop there. They downloaded our source, found the problem, built a patch and attached it to the bug report. So all I had to do was apply the patch and start the errata process.   This is the type of stuff that can't happen in a closed source system, and is why Open Source is better...

Open source is like The Elves and the Shoemaker, just don't tell my boss. :^)

James Morris: New GPG Key

jamesm — 2011-10-23T13:02:34+00:00

In support of the new kernel.org security scheme, I’ve created a new 4096 bit RSA key:

pub   4096R/FA118320 2011-10-23
      Key fingerprint = 4ED7 50E6 F7F9 ACED 29DD  B750 EB75 1458 FA11 8320
uid   James Morris <jmorris@namei.org>

I’ve published the key via the MIT key server.

I’ll continue to host the security subsystem tree on selinuxproject.org until things are fully set up on kernel.org.

Dan Walsh: 10 things you probably did not know about SELinux.. #8 How to remove a port from a port type?

dwalsh@redhat.com — 2011-10-21T15:01:11+00:00

How do you remove a network port from a network port type?

First a little explanation. Linux contains 65536 network ports for both UDP and TCP.
SELinux uses types to group network ports together. If you want to see a listing of the port types on the system you can execute:

semanage port -l
SELinux Port Type              Proto    Port Number

afs_bos_port_t                 udp      7007
afs_client_port_t              udp      7001
afs_fs_port_t                  tcp      2040
afs_fs_port_t                  udp      7000, 7005
...

Then we write rules in SELinux like

allow httpd_t http_port_t : tcp_socket name_bind ;

This rules says the apache process can execute the bind command using any port that is currently labeled http_port_t.

# semanage port -l | grep http_port_t
http_port_t                    tcp      80, 443, 488, 8008, 8009, 8443

Now a fairly common question that gets asked is, can I remove these ports.   IE I do not want to allow apache to bind to port 8008.

How would I do this?

The simplest thing to do is to redefine port 8008 as a different port type that httpd can not bind to.

The default port type for all unassigned ports > 1024 is unreserved_port_t or ephemeral_port_t (Fedora 16)

# semanage port -l | grep ^unreserved_port_t
unreserved_port_t              tcp      1024-32767, 61001-65535
unreserved_port_t              udp      1024-32767, 61001-65535
# semanage port -l | grep ^ephemeral_port_t
ephemeral_port_t               tcp      32768-61000
ephemeral_port_t               udp      32768-61000

Note SELinux will use a more specific port type if the port has been defined, for example when the kernel sees tcp port 8008, it will use http_port_t rather then unreserved_port_t.

But the admin can override this by adding his own port definition.

# semanage port -m -t unreserved_port_t -p tcp 8008

To prove this worked, I tested using apache.

# sed -i 's/Listen 80/Listen 8008/g' /etc/httpd/conf/httpd.conf
# semanage port -m -t unreserved_port_t -p tcp 8008
# service httpd restart
Restarting httpd (via systemctl): Job failed. See system logs and 'systemctl status' for details. [FAILED]
# semanage port -d -p tcp 8008
# service httpd restart
Restarting httpd (via systemctl):                          [ OK ]

NOTE:

Be careful doing this, because you have just changed the definition of http_port_t for ALL domains, not just the httpd_t domain.   Meaning if you were running firefox with a sandbox_web_t sandbox on the same machine, the firefox would no longer be able to connect to port 8008, because sandbox_web_t is only allowed to connect to http_port_t and 8008 is no longer defined as 8008.

Dan Walsh: How should you disable IPV6?

dwalsh@redhat.com — 2011-10-19T13:34:07+00:00

Blogging twice in the same day, a new record...

Lots of people are out there disabling IPV6, and when you do invariably you get a flood of AVC messages about different confined domains asking the kernel to load the kernel module net-pf-10.

type=AVC msg=audit(10/18/11 23:40:10.233:978087) : avc: denied { module_request } for pid=32265 comm=pickup kmod="net-pf-10" scontext=system_u:system_r:postfix_pickup_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=system

Now I am not recommending that you enable or disable IPV6, but if you do want to disable it and run with SELinux turned on, please read the following:

Eric Paris reports

"I believe the networking kernel community recommends (and it will shut up these AVCs) that IPv6 be disabled by:

echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6

It still loads the module but unhooks almost all of the calls into the module. (apparently the IPv6 module has become so ingrained in the kernel that a number of other things, like certain firewall modules, require it. I didn't design it, I'm just telling it how it is) "

We recommend that you do not disable the ipv6 module but add

net.ipv6.conf.all.disable_ipv6 = 1

to /etc/sysctl.conf

And the AVC messages should go away.

The setroubleshoot plugin in Fedora reflects this info.

Dan Walsh: Making a domain "unconfined"

dwalsh@redhat.com — 2011-10-19T13:01:03+00:00

In a couple of previous blogs I talked about permissive and unconfined domains.

http://danwalsh.livejournal.com/24537.html?thread=176857
http://danwalsh.livejournal.com/42394.html

Today we had a question about how to I disable_trans on pam_console_t in Red Hat Enterprise Linux 6.
If you have used RHEL5 or have read one of the blogs above you will realize in RHEL5 we had a lot of booleans DOMAIN_disable_trans. The idea was to run these domains without SELinux protection. We quickly figured out that this was a bad idea. Other confined domains would start failing because the process they were supposed to communicate with would be running with a different label. Or files created by the disabled_trans DOMAIN would now get created with the wrong labels.

In RHEL6 we introduced permissive domains, so that you could run the entire system locked down but pick a few process domains to run in permissive mode. The nice thing about this is we can figure out what the domain wants to do and improve the policy.

Miroslav Grepl came up with a third solution to the problem today. Basically if a administrator wants to just allow a domain to do what it wants, he can add a policy module that turns the domain into an unconfined domain. This will work on all Fedora releases and RHEL5 as well as RHEL6. And is a much better solution then the disable_trans boolean.

If you wanted to run pam_console_t as an unconfined domain, you would first create a file call mypam.te.

# cat mypam.te
policy_module(mypam, 1.0)
gen_requires(`
type pam_console_t;
')
unconfined_domain(pam_console_t)
# make -f /usr/share/selinux/devel/Makefile
# semodule -i mypam.pp

Now pam_console_t will be an unconfined domain, but any confined domain that needs to interact with it will still work. All of the file transition rules will still happen, so the system should stay labelled properly. And no AVC messages will be generated about this domain.

Dan Walsh: setrans is a handy little tool to analyze policy transitions

dwalsh@redhat.com — 2011-10-12T16:09:47+00:00

For several years we have had a SELinux tool set called setools that allows you to analyse policy. I use sesearch and seinfo all the time for looking at policy. setools includes a tcl/tk interface, called apol, that allows you to ask really complicated questions in policy about whether one process and read/write a file, even through process transitions. The problem is the GUI is a little clunky, and I don't like GUIs.

A few years ago I added python bindings for sesearch and seinfo to the setools/apol libraries. These python interfaces are used within some of the semanage tool chain.

I often see an AVC about one domain not being able to write to another domains files. Usually these types of avc's are caused by passing an open file descriptor, like stdout, from one process to another process. Sometimes I am puzzled by the relationship between the two domains. I recently got an AVC about ldconfig_t not being able to write to a chr_file labeled mock_var_lib_t. How does the ldconfig program even know about a chr_file labeled mock_var_lib_t? How did did mock transition to the ldconfig domain?

Well I wrote a tool, setrans, that helps answer these question. The tool takes two domain/process types and attempts to see if the first
type can transition to the second type, and then print all of the intermediary types that it used to get from one domain to the other.

./setrans init_t httpd_t
init_t --> httpd_t

./setrans mock_t ldconfig_t
mock_t --> mount_t --> insmod_t --> initrc_t --> ldconfig_t

./setrans mock_t user_t
mock_t --> mount_t --> insmod_t --> initrc_t --> stunnel_t --> rlogind_t --> remote_login_t --> unpriv_userdomain --> user_t
mock_t --> mount_t --> insmod_t --> initrc_t --> crond_t --> user_t
mock_t --> mount_t --> insmod_t --> initrc_t --> getty_t --> local_login_t --> userdomain --> user_t
mock_t --> mount_t --> insmod_t --> initrc_t --> xdm_t --> gkeyringd_domain --> user_t

I know that it is not complete and will not show all paths, but it is pretty useful for quick analyses of the policy.

Dan Walsh: Fedora 16 New SELinux Feature part IV - Shrinking policy

dwalsh@redhat.com — 2011-09-30T18:30:05+00:00

Back in July the systemd team was trying to decrease the boot time on early versions of Fedora 16. They found that with a Solid State disk, SELinux policy load and relabel was quickly becoming the biggest pig as far as boot time. So they added some log messages that showed how long it was taking to just read the selinux policy off of disk and load it into the kernel.

Lennart Poettering announced systemd 32 with the following message.

Primarily bugfixes, and one really cool improvement: we can now load the SELinux policy without having to reexecute ourselves. This is much
prettier and saves up to 70ms or so. I also added some basic profiling output for SELinux which unfortunately shows that SELinux costs around
5s on every boot on f16 (and that on my really fast machine!). Sad. 

Look for output like this:

[   10.727004] systemd[1]: Successfully loaded SELinux policy in 3s 270ms 896us.
[   10.769204] systemd[1]: Successfully loaded SELinux database in 41ms 700us, size on heap is 460K.
[   11.943903] systemd[1]: Relabelled /dev and /run in 1s 125ms 738us.

He even added these lines to every boot, so everyone would know how much time SELinux was costing them on boot.

Nothing like public embarrassment to make you take action.

Shame is a great motivator. :^(

I decided to take a look at the policy using the sesearch tools. I wanted to figure out where all the rules were coming from, and whether we had some duplicates we could remove. The first thing I noticed was there were thousands of rules related to network ports. To me there seemed to be way to many. I began to investigate and found that M4 macro expansion was the problem.

SELinux policy is written using m4. Over the years we have written lots of macros which policy writers take advantage. We call these macros interfaces. Another feature of SELinux policy is the use of attributes. Attrinbutes are a way of grouping lots of types (init_t, httpd_t) together. You can create a new user type say staff_t and add an attribute say usertype. Now you write rules regarding the usertype that affect all users.

allow usertype etc_t:file read;

SELinux also defines network port attributes like port_type and reserved_port_type. All network ports get the attribute port_type and all ports < 1024 get the attribute reserved port type. Well M4 has a cool feature "negation".   SELinux policy was using negation in many places including defineing unreserved_ports. For example in Fedora 15 we have an interface that says.

interface(`corenet_tcp_bind_all_unreserved_ports',`
    gen_require(`
        attribute port_type, reserved_port_type;
    ')

    allow $1 { port_type -reserved_port_type }:tcp_socket name_bind;
')

All types that need to bind to ports > 1023 would then using this interface.

/usr/bin/ssh (ssh_t) needs to be able to setup alternate ports to allow a tunnel connection between a remote sshd service and the local machine, so we allow it to bind to any port > 1023 using the following line:

corenet_tcp_bind_all_unreserved_ports(ssh_t)

Seems like a simple rule to add, until you understand how m4 works with negation. M4 expands out all the attributes into their types and then writes a rule for each type that matches. A rule like this could end up adding 100s of allow rules. For every type that is a port_type and not a reserved_port_type, a rule would be written allowing ssh_t to bind to the port.

allow ssh_t amqp_port_t:tcp_socket name_bind;
allow ssh_t asterisk_port_t:tcp_socket name_bind;
...

I found that if I defined a new attribute "unreserved_port_type", and rewrote the interface to something like.

interface(`corenet_tcp_bind_all_unreserved_ports',`
    gen_require(`
        attribute port_type, reserved_port_type;
    ')

    allow $1 unreserved_port_type:tcp_socket name_bind;
')

I ended up with only one rule generated by

corenet_tcp_bind_all_unreserved_ports(ssh_t)

allow ssh_t unreserved_port_type:tcp_socket name_bind;

Turns out we had lots and lots of interfaces where we used the negation.

    dontaudit $1 { port_type -port_t }:dccp_socket name_bind;
    files_read_all_dirs_except($1, $2 -shadow_t)

I went through the entire policy and switched to using only attributes like unreserved_port_type attributes and shrunk the size of policy by about 80 %.

What is really nice, you can check the size of policy using seinfo.
----------------------------
As time went on F15 machine:
$ seinfo
Statistics for policy file: /etc/selinux/targeted/policy/policy.24
Policy Version & Type: v.24 (binary, mls)
Allow:          282444
Dontaudit:      184516

and on F16 machine:

$ seinfo
Statistics for policy file: /etc/selinux/targeted/policy/policy.26
Policy Version & Type: v.26 (binary, mls)
Allow:           88242
Dontaudit:       11302

Tools used to load the policy run about 3 times as fast.

Conclusion:

Tom London looked at the change on his machine and found

And comparing 'old vs. new' boot times, first the old:

Jul 28 06:39:29 tlondon systemd[1]: Startup finished in 3s 336ms 755us (kernel) + 11s 625ms 240us (initrd) + 28s 189ms 914us (userspace) = 43s 151ms 909us.

And now the 'new':

Jul 29 06:00:41 tlondon systemd[1]: Startup finished in 1s 844ms 542us (kernel) + 4s 999ms 977us (initrd) + 29s 239ms 766us (userspace) = 36s 84ms 285us.

6.5 seconds less in initrd.

A second feature of this change is we are now taking up probably 80% less kernel memory...

RHEL 6
# du -s /etc/selinux/targeted/policy/policy.24
6004 /etc/selinux/targeted/policy/policy.24

Fedora 16:

# du -s /etc/selinux/targeted/policy/policy.26
2156 /etc/selinux/targeted/policy/policy.26

And Fedora 16 has more domains, types and rules...

At some point I should probably back port these changes to RHEL6.

Dan Walsh: Fedora 16 New SELinux Feature part III - permissivedomains module

dwalsh@redhat.com — 2011-09-29T13:17:50+00:00

As has been stated in previous blogs we have three types of unconfined processes on Fedora.

We have unconfined_domain() system processes. initrc_t, init_t, kernel_t, ...
We have unconfined_domain() user processes. unconfined_t,
We have permissivedomains

Up until now you can remove unoconfined system processes by disabling the unconfined.pp module.

semodule -d unconfined

You can disable the unconfined users by removing unconfined user mappings and then disabling unconfineduser.pp

# semanage login -m -a staff_u __default__
# semanage login -m -a staff_u root
You might need to log out and back in now as sysadm_t and make sure there are no unconfined_u/unconfined_t processes running. Also make sure that you do not have any entries in /etc/sudoers for unconfined_t or files left over in /tmp or /var/db/sudo.
# semanage user -d unconfined_u
# semode -d unconfineduser

But you could not get rid of permissive domains, since the permissive flag was in individual policy modules. In F16 we re-factored all of the permissive domain declarations into a new module called permissivedomains.pp. If you want to remove all permissive domains from your system
you can execute

semodule -d permissivedomains

# semanage permissive -l
Builtin Permissive Types

Customized Permissive Types

This will give you a fully locked down machine.

Thomas Biege (Security): 4th German OWASP Security Day

Thomas (noreply@blogger.com) — 2011-09-22T01:09:14+00:00

My submission to the 4th German OWASP Security Day was accepted. Now let's see if we can accept their OWASP license that needs to be signed...

kostenloser Counter

Thomas Biege (Security): I am leaving the SUSE Security Team...

Thomas (noreply@blogger.com) — 2011-09-21T03:25:20+00:00

After 12 years I am leaving the SUSE Security-Team... just to support them! :-)

Like a satellite I was spun-off from mother earth. Flying around the SUSE Security Team as project-manager to take care of our products before they get released working hand-in-hand with Marcus and his team that (mostly but not exclusively) takes care of the security of already released products.

kostenloser Counter

James Morris: Linux Security Summit 2011 – Presentation Slides

jamesm — 2011-09-20T05:41:52+00:00

Just over a week ago, the 2011 Linux Security Summit was held in Santa Rosa CA, co-located with Linux Plumbers. It ran for a day, starting with refereed presentations, and then round-table discussions.

The home page for the summit is on the kernel.org wiki, and is currently unavailable, so I’m posting links to the slides here:

* Smack is Alive and Well
Casey Schaufler, Intel

* An Overview of the Linux Integrity Subsystem: Use Cases and Demonstration
David Safford and Mimi Zohar, IBM

* Digital Signature support for IMA/EVM
Dmitry Kasatkin and Ryan Ware, Intel (presented by Casey)

* Protecting the Filesystem Integrity of a Fedora 15 Virtual Machine from Offline Attacks using IMA/EVM
Peter Kruus, The Johns Hopkins University Applied Physics Laboratory

* Efficient, TPM-free system integrity checking with device mapper: dm-verity
Will Drewry and Mandeep Baines, Google

* The Case for SE Android
Stephen Smalley, NSA

Roundtable discussions:

* Kernel Hardening [no slides]
Lead by Kees Cook, Canonical and Will Drewry, Google

* LSM Architecture
Lead by Kees Cook, Canonical and Casey Schaufler

The SE Android talk was a last minute replacement for Ryan Ware’s talk on MeeGo (Ryan was unfortunately not able to make it).

See the write-ups by by Paul Moore and LWN.

Feedback so far has been positive. I think it’s valuable for the security developers to get together like this, after spending the rest of the year working remotely with each other. Next year, we’ll likely be looking at co-locating with LPC/KS/LinuxCon in San Diego. It may be worth thinking about expanding to a two-day event, with the first day following the same format, but then splitting into project groups on day two for BoFs/hack sessions.

Contact the program committee if you have any suggestions.

I’d like to thank the LPC folk, and especially Jesse Barnes, for allowing us to co-locate and taking care of all of the logistics — all we had to do was organize the talks and turn up. Also thanks to the speakers, discussion leaders and attendees. See you next year!

Paul Moore: Wrapping Up The 2011 Linux Security Summit

2011-09-09T06:55:34+00:00

We just closed the doors on the 2011 Linux Security Summit a few hours ago and I wanted to jot down a few notes while everything was still fresh in my mind. Once again, a big thanks to all of our presenters, James Morris and the rest of the organizing committee; my personal opinion is that the summit was a success this year and I look forward to doing this again in 2012.

Just as in the past, presentations will be posted at the wiki below once kernel.org comes back online.

http://security.wiki.kernel.org/index.php/LinuxSecuritySummit2011

Smack is Alive and Well, Casey Schaufler

This presentation started with a brief introduction to Smack and then moved on to presenting the recent users, motivations and focus. While Smack has been incorporated into at least one general purpose Linux Distribution, Ubuntu, over the past year or two Smack has grown increasingly focused on small and embedded devices. Functionality wise, Smack has gained several new additions including process labels and transmutable directories. Process labels allow an executable file to be started with a label specified in the file's xattrs and not the parent process's attributes. Transmutable directories allow two differently labeled processes to write into each other's directories without requiring full write access to the other label; this should make it much easier to share files and data between labels. Beyond the new functionality, performance improvements, increased Linux Test Project coverage and improved consistency between AF_UNIX and AF_INET sockets have seen their way, or will soon see their way into Smack.

MeeGo platform security, including Smack userspace: http://meego.gitorious.org/meego-platform-security

The Case for SE Android, Stephen Smalley

This presentation discussed a recent effort to prototype a SELinux implementation for Android. While SELinux is well known in desktop and server Linux environments, it is still rare in mobile and embedded systems due to concerns around resource usage and differences in both the kernels and userspace. This talk explained the basic Linux/Android differences and what was needed to enable SELinux on the Android platform. Resource issues around policy size were addressed through a greatly simplified SELinux policy which avoided per-application policy and relied on a relatively simple rule set. Finally, the effectiveness of the prototype was evaluated by examining a recent Android vulnerability with a known exploit and determining the effectiveness of the SELinux Android port in preventing the exploit. In the end, this remains a prototype at present, designed to investigate Android's security capabilities, but it shows quite a bit of promise and has a lot to offer beyond the current Android security functionality.

Overview of the Linux Integrity Architecture, David Safford and Mimi Zohar

The Linux Integrity Architecture project has seen a lot of activity over the past few years and the presentation started off with an overview of project, including a status update on where each piece of functionality stood with respect to upstream and established distributions. The good news is that almost all of the IMA project is either currently upstream or patches have been submitted and are being discussed on the related mailing lists. One of the presentation highlights was a demo tying together the IMA principals and virtualization to demonstrate a "Trusted Cloud". While there is work to be done, the IMA project has made great strides and already offers some impressive functionality.

IMA project website: http://linux-ima.sf.net

Digital Signature Support for IMA/EVM, Dmitry Kasatkin and Casey Schaufler

This presentation addressed a problem common to system and device manufacturers who install a single "golden image" on each system they ship: how do you reconcile the business need of a single install image with a TPM based EVM HMAC which uses a per-device key stored in the TPM? One potential answer is to expand on the EVM mechanism to support public key digital signatures in addition to the TPM based HMAC. When the devices are initially installed, a public key certificate is installed into the Linux Kernel keyring via an initrd with the filesystem using digital signatures for the EVM xattr in place of the traditional HMAC. As the files are accessed, the EVM digital signature is verified, and if correct, it is replaced by a TPM generated HMAC. If the EVM digital signature verification fails, access is denied in the same way as if the EVM HMAC verification had failed.

Protecting the Filesystem Integrity of a Fedora 15 Virtual Machine from Offline Attacks using IMA/EVM, Peter Kruus

This presentation covered some work being done to better secure Fedora 15 guests running on VMWare ESXi while the guests were both running and offline. All systems are vulnerable to offline attacks, but in the case of virtual systems, offline vulnerabilities can sometimes be much easier to exploit due to the availability of the host system and guest storage volumes. In order to help mitigate this problem, the presenter leveraged the existing IMA/EVM support in Fedora 15 to verify the integrity of critical system files, but unfortunately due to missing vTPM support in VMWare ESXi the presenter was unable to leverage TPM based HMACs in the EVM attributes. The solution was to use a passphrase protected key which was loaded at boot through a combination of the system's initrd and dracut. While this solution does provide an increased level of protection against attack, for this approach to be truly successful, full vTPM support is needed in the hypervisor to allow the guest to utilize the TPM. While vTPM patches have been submitted for QEMU/KVM, the state of the vTPM in VMWare ESXi is unknown.

Integrity-checked Block Devices with Device Mapper, Will Drewry and Mandeep Baines

This presentation dealt with an enhancement to the Linux Kernel Device Mapper to perform block level integrity verification. This solution was designed primarily for the Linux based Chromium OS running on modest netbook class hardware where boot performance was a significant requirement. Helping to simplify the solution was the fact that the system is very well defined and operates in a read-only mode such that the integrity verification mechanism does not need to worry about online updates to the storage volume. The solution, dm-verity, uses a slightly modified hash tree, with the root hash specified on the kernel command line to quickly verify the integrity of the entire block device. Optimization is ongoing, but already the developers are able to boot a ~800MB Chromium OS root partition in ~1.2s on an Atom CPU using a SSD storage volume. While this integrity verification solution may not lend itself quite as well to general purpose systems as the TPM/IMA based solutions, it presents a novel solution that helps solve Chromium OS's needs in a a high performance, low cost manner.

Kernel Hardening Roundtable, Kees Cook and Will Drewry

This roundtable started with a discussion on the different kernel interfaces where the kernel is exposed to user input, malicious or otherwise. From here the focus shifted to how the existing security mechanisms, such as DAC, LSM and capabilities, impact the kernel's exposed interfaces - for better or worse. At this point it was clear, if it wasn't already, that the Linux Kernel remains far too exposed to malicious users/applications and some additional hardening techniques are needed.

While many hardening ideas were discussed, the two main points of discussion revolved around system call filtering/reduction and the hardening techniques found in grsecurity. With respect to system call filtering, work has been ongoing this year to expand the mainline seccomp functionality to be more flexible and useful for a wider range of applications. Plenty of discussion has already occurred on the mailing lists and more is expected as the enhanced seccomp developer has promised a new round of patches soon. Similarly, work has recently been ongoing to decompose the rejected grsecurity patch and repackage it in a series of patches which will hopefully be acceptable to the upstream kernel maintainers.

Sandbox powered by the current mainline seccomp: http://code.google.com/p/seccompsandbox
Ubuntu Linux Kernel hardening tasks: http://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Upstream_Hardening
Linux Kernel hardening mailing lists: http://www.openwall.com/lists (see the kernel-hardening list)

LSM Architecture Roundtable, Kees Cook and Casey Schaufler

This roundtable dealt primarily with the issues related to multiple LSMs, from APIs and determining which LSM was enabled in the kernel to architectural issues blocking multiple concurrent LSMs. With respect to determining the active LSM and LSM APIs, the discussion was largely a group brainstorming session with developers discussing the pros and cons of various solutions; while most agreed the a general LSM userspace API was more problem than it was worth, there was some general agreement on LSM conventions that should help unify some of the most basic LSM API functionality in the future.

This discussion around running multiple concurrent LSMs was much more focused, with patches being proposed as recently as February, although everyone did agree that the patches had serious limitations due to shortcomings with the LSM hooks/blobs in the kernel. In the end, several inherent blockers to concurrent LSM operation remained, but the "religious" arguments against the idea seemed to be less than in past years.

Dan Walsh: Fedora 16 Alpha available part II, New SELinux Feature/File Name Transitions

dwalsh@redhat.com — 2011-08-30T13:41:01+00:00

Fedora 16 Alpha was just released: The announcement include the following:

SELinux Enhancements. SELinux policy package now includes a pre-built policy that will only rebuild policy if any customizations have been made. A sample test run shows 4 times speedup on installing the package from 48 Seconds to 12 Seconds and max memory usage from 38M to 6M. In addition to that, SELinux file name transition allows better policy management. For instance, policy writers can take advantage of this and write a policy rule that states, if a SELinux unconfined process creates a file named resolv.conf in a directory labelled etc_t, the file should get labeled appropriately. This results is less chances of mislabeled files. Also, from this release onwards, selinuxfs is mounted at /sys/fs/selinux instead of in /selinux. All the affected components including anaconda, dracut, livecd-tools and policycoreutils have been modified to work with this change.

Named File Transitions Feature

This feature was added to F16 to make labelling files easier for users and administrators. The goal is to prevent accidental mislabelling of file objects.

Accidental mislabelling

Users or administrators often create files or directories that do not have the same label as the parent directory, and then forget to fix the label. An example of this would be the administrator going into the /root directory and creating the .ssh directory. In previous versions of Fedora, the directory would get created admin_home_t, even though the policy requires it to be labelled ssh_home_t. Later when he tries to use the content of the .ssh directory to login without a password, sshd (sshd_t) fails to read the directories contents because sshd is not allowed to read files labelled admin_home_t.

Another example would be a user creating the public_html directory in his home directory. The default label for content in the home directory is user_home_t, but SELinux requires the public_html directory to be labelled http_user_content_t or the apache process (httpd_t) will not be allowed to read it.

File Transitions Policy

Policy writers have always be able to write a file transition rule that includes the type of the processes creating the file object (NetworkManger_t), the type of the directory that will contain the file object (etc_t) and the class of the file object (file). Then specify the type of the created object (net_conf_t).

filetrans_pattern(NetworkManager_t, etc_t, file, net_conf_t)

This policy line says that a process running as NetworkManager_t creating any file in a directory labelled etc_t will create it with the label net_conf_t.

Named File Transitions Policy

Eric Paris added a cool feature to the kernel that allows the kernel to label a file based on 4 characteristics instead of just three. He added the base file name. (Not the path).

Now we can write policy rules that state:

If the unconfined_t user process creates the ".ssh" directory in a directory labelled admin_home_t, then it will get created with the label ssh_home_t.

filetrans_pattern(unconfined_t, admin_home_t, dir, ssh_home_t, ".ssh")
If the staff_t user process creates a directory named public_html in a directory labeled user_home_dir_t it will get labeled

http_user_content_t. filetrans_pattern(staff_t, user_home_dir_t, dir, http_user_content_t, "public_html")

Additionally we have added rules to make sure if the kernel creates content in /dev it will label it correctly rather then waiting for udev to fix the label.

filetrans_pattern(kernel_t, device_t, chr_file, wireless_device_t, "rfkill")

Bottom line.

There should be less occurrences of accidental mislabels by users and hopefully a more secure and better running SELinux system.

Dan Walsh: Fedora 16 Alpha available, New SELinux Feature/Prebuilt Policy.

dwalsh@redhat.com — 2011-08-30T13:37:13+00:00

Fedora 16 Alpha was just released: The announcement include the following:

SELinux Enhancements.
SELinux policy package now includes a pre-built policy that will only rebuild policy if any customizations have been made. A sample test run shows 4 times speedup on installing the package from 48 Seconds to 12 Seconds and max memory usage from 38M to 6M. In addition to that, SELinux file name transition allows better policy management. For instance, policy writers can take advantage of this and write a policy rule that states, if a SELinux unconfined process creates a file named resolv.conf in a directory labelled etc_t, the file should get labeled appropriately. This results is less chances of mislabeled files. Also, from this release onwards, selinuxfs is mounted at /sys/fs/selinux instead of in /selinux. All the affected components including anaconda, dracut, livecd-tools and policycoreutils have been modified to work with this change.

Pre-Built Policy

We made major changes to the selinux-policy-TYPE rpm. (selinux-policy-targeted-3.10.0-21.fc16)

The rpm now includes a pre-built /etc/selinux/targeted/policy/policy.26. This policy file can be loaded right away in a fresh install. In all previous versions of SELinux for RHEL and Fedora, we rebuilt this file in the post install. The reason for this is we need to recompile in local customizations that the user/administrator might have made on your system. Additionally if any package shipped with a policy we would need to recompile in those policy packages. But as the size of policy grew we were seeing Anaconda installation times grow and memory requirements grow because of selinux-policy package. We were even seeing virtual machine installations blow up on selinux-policy package installs because of limited memory. When we looked at the problem, we realized that on initial install of policy, no user would have made local customizations and very few packages are shipping with their own policy.

I reworked the tools to include the policy packages within the payload and now the package will check in the pre-install if there was any local customizations, if yes, the post install will recompile the policy, but if not the policy will just install.

We also used to have to ship all of the policy modules, over 300, in the directory /usr/share/selinux/targeted and these would be copied into /etc/selinux/targeted/modules/active/, were we would never touch the files in /usr/share/selinux/targeted again. Now we install directly into /etc/selinux/targeted/modules/active/.

What you should see is faster initial installs and faster selinux-package updates. In Fedora 15 a policy-package update would take around 45-50 seconds, in Fedora 16 on an unmodified selinux-policy system it should take < 15 seconds. If you are updating from Fedora 15 the first time, it will still take a long time, but the next update should go quick. If you have modified the SELinux system by adding pp
files you will still see the recompile times that you always have. :^(

Dan Walsh: Fedora 16 Alpha available part II, New SELinux Feature/File Name Transitions

dwalsh@redhat.com — 2011-08-26T13:28:51+00:00

Fedora 16 Alpha was just released:

The announcement include the following:

SELinux Enhancements. SELinux policy package now includes a pre-built policy that will only rebuild policy if any customizations have been made. A sample test run shows 4 times speedup on installing the package from 48 Seconds to 12 Seconds and max memory usage from 38M to 6M. In addition to that, SELinux file name transition allows better policy management. For instance, policy writers can take advantage of this and write a policy rule that states, if a SELinux unconfined process creates a file named resolv.conf in a directory labelled etc_t, the file should get labeled appropriately. This results is less chances of mislabeled files. Also, from this release onwards, selinuxfs is mounted at /sys/fs/selinux instead of in /selinux. All the affected components including anaconda, dracut, livecd-tools and policycoreutils have been modified to work with this change.

Named File Transitions Feature

This feature was added to F16 to make labelling files easier for users and administrators.

The goal is to prevent accidental mislabelling of file objects.

Accidental mislabelling

Users or administrators often create files or directories that do not have the same label as the parent directory, and then forget to fix the label. An example of this would be the administrator going into the /root directory and creating the .ssh directory.

In previous versions of Fedora, the directory would get created admin_home_t, even though the policy requires it to be labelled ssh_home_t. Later when he tries to use the content of the .ssh directory to login without a password, sshd (sshd_t) fails to read the directories contents because sshd is not allowed to read files labelled admin_home_t.

Another example would be a user creating the public_html directory in his home directory. The default label for content in the home directory is user_home_t, but SELinux requires the public_html directory to be labelled http_user_content_t or the apache process (httpd_t) will not be allowed to read it.

File Transitions Policy

Policy writers have always be able to write a file transition rule that includes the type of the processes creating the file object (NetworkManger_t), the type of the directory that will contain the file object (etc_t) and the class of the file object (file). Then specify the type of the created object (net_conf_t).

filetrans_pattern(NetworkManager_t, etc_t, file, net_conf_t)

This policy line says that a process running as NetworkManager_t creating any file in a directory labelled etc_t will create it with the label net_conf_t.

Named File Transitions Policy

Eric Paris added a cool feature to the kernel that allows the kernel to label a file based on 4 characteristics instead of just three. He added the base file name. (Not the path).

Now we can write policy rules that state:

If the unconfined_t user process creates the ".ssh" directory in a directory labelled admin_home_t, then it will get created with the label ssh_home_t.

filetrans_pattern(unconfined_t, admin_home_t, dir, ssh_home_t, ".ssh")
If the staff_t user process creates a directory named public_html in a directory labeled user_home_dir_t it will get labeled http_user_content_t.

filetrans_pattern(staff_t, user_home_dir_t, dir, http_user_content_t, "public_html")

Additionally we have added rules to make sure if the kernel creates content in /dev it will label it correctly rather then waiting for udev to fix the label.
filetrans_pattern(kernel_t, device_t, chr_file, wireless_device_t, "rfkill")

Bottom line.

There should be less occurrences of accidental mislabels by users and hopefully a more secure and better running SELinux system.

Dan Walsh: sVirt to the Rescue

dwalsh@redhat.com — 2011-08-25T18:07:17+00:00

At the recent Black Hat conference Nelson Elhage presented:

Virtualization Under Attack: Breaking out of KVM

The exploit, CVE-2011-1751, would allow a cracker to execute code in qemu-kvm process on the host.

Note: Red Hat fixed this problem back in May 2011 prior to the publication of the paper and exploit. Customers who applied our security updates are not affected by this issue. So 0 days of exposure.

In the presentation there is this bullet point:

qemu-kvm is often sandboxed using SELinux or similar, meaning that
successful exploitation will often require a second privesc within the
host.
(Fortunately, Linux never has any of those)

This means that SELinux/sVirt on Red Hat Enterprise Linux and Fedora confines this outbreak!

In a previous blog, Fun with sVirt., I showed how you can simulate this vulnerability to see what access was available. Not much...

Nelson mentioned SELinux sandboxing could be bypassed by a theoretical second "privesc" vulnerability, meaning a bug in the kernel. SELinux or any kind of Mandatory Access Control is enforced by the Kernel. Bugs in that Kernel, that a process is allowed to access, can subvirt SELinux. But SELinux is putting up a significant second barrier to the cracker.

Security is all about Layers, making each layer as secure as possible and then fixing vulnerabilities as quickly as you know about them.

This presentation exposes the risk associated with virtualization, but also shows the secondary security controls Linux KVM is using to minimize the risk and giving us time to fix problems as soon as we know about them.

Bottom line, this is why you leave SELinux enabled in enforcing mode. :^)

Dominick Grift: Git daemon and SELinux with RHEL6

Dominick "domg472" Grift (noreply@blogger.com) — 2011-08-23T12:17:12+00:00

RHEL6 does not ship with a manual page for configuring Git daemon SELinux policy, and so decided to publish a demonstration on youtube:

Part 1. Git system daemon, shared repositories.

http://www.youtube.com/watch?v=vgm89P5nbBQ

Part 2. Git session daemon, personal repositories.

http://www.youtube.com/watch?v=XHEPj80217o

By the way you can look at the manual page (source) here:

http://git.fedorahosted.org/git/?p=selinux-policy.git;a=blob;f=man/man8/git_selinux.8;h=e9c43b190c394f8ea7e68d9dd29f45c831340bf5;hb=ccadbe7d6ae709cdfd3b06d496477e069a2f13ee

Paul Moore: Twitter Too

2011-08-15T22:39:18+00:00

To add to the recent email updates, I thought I would mention that I'm now on twitter too at @paul_via_tweet. Not much there right now, but since all the "cool kids" are on the twitter these days, how could I resist?

Dan Walsh: Fedora 16 is about to go to Alpha release, some SELinux changes.

dwalsh@redhat.com — 2011-08-11T13:24:44+00:00

First with the move to systemd, we were asked to move the /selinux file system to a more standard location.

From this point forward the selinuxfs will be mounted under /sys/fs/selinux.

This seems to be the new location for kernel interface file systems, like cgroup

# ls /sys/fs/
cgroup ext4 fuse selinux

libselinux has been modified to mount the selinuxfs file system on the /sys/fs/selinux directory if it exists, otherwise libselinux will fall back to mounting on the /selinux directory if it exists.

One problem I foresee and we are beginning to fix is any application that hard coded "/selinux" in to the application. So far we have had to fix anaconda, livecd-tools, policycoreutils, and dracut. In most cases you should use the command line tools like setenforce or selinuxenabeled, or use the python bindings

python
>>> import selinux
>>> print (selinux.is_selinux_enabled())
1

And not hard code the path.

Another option is to grep /proc/self/mountinfo

# grep selinuxfs /proc/self/mountinfo | head -1 | awk '{ print $5 }'
/sys/fs/selinux

If you know of any applications that hard code /selinux into them, please let me know and I can work with the maintainer or developer to fix the code.

Paul Moore: New Email Address Part Two

2011-08-10T18:08:11+00:00

Hello again, last week I made a quick post to say that my @hp.com email address was going away; the reason for that, as many had guessed, was that I was leaving HP for a new employer. As of this past Monday, August 8th, 2011, I'm happy to say that I am now working for Red Hat. This should be good news for anyone interested in the Linux labeled networking bits and the assorted LSM network access controls as my new employer should allow me to spend more time maintaining and working on these things than I have over the past few years.

So, with a new job comes a new email address; you can continue to send me email at paul@paul-moore.com, but now you can also reach me at pmoore@redhat.com.

Paul Moore: New Email Address

2011-08-01T21:16:45+00:00

Just a quick update to let everyone know that my @hp.com email address is going to stop working on Friday, August 5, 2011. If you need to get in touch with me please send me email at paul@paul-moore.com.

Thomas Biege (Security): Scanny will replace the ror-sec-scanner

Thomas (noreply@blogger.com) — 2011-07-26T05:08:50+00:00

David and Flavio created a new github project to replace my ror-sec-scanner. "Scanny" doesn't uses regex but the AST and emits fewer false positives. So lets start adding rules/checks to it to become more powerful.

kostenloser Counter

Russell Coker (security): SE Linux File Context Precedence

etbe — 2011-07-24T05:54:20+00:00

In my previous post I expressed a desire to use regular expressions for files that may appear in multiple places in the tree due to bind mounts for /run and /var/run etc [1]. However there is a problem with this idea.

The SE Linux file labeling program restorecon reads the file /etc/selinux/$SELINUXTYPE/contexts/files/file_contexts which contains a set of regular expressions to assign labels to files. That file is ordered and the last entry which matches is the one that counts. When the file_contexts file is created the order is based on how many characters at the start of the file specification aren’t regular expression meta-characters. For example the entry “/.*” is at the top of the file (and therefore has the lowest precedence), which makes it the catch-all entry for files that have no other match. So an entry for “/var/run/REGEX” will have a higher precedence than one for “/var/REGEX”, this means however that when I replaced the “/var/run” part with a regular expression then it had a lower precedence and it didn’t work properly.

I should have remembered this as I did a lot of work on setfiles (which became restorecon) in the early days. I have now developed a new way of solving this and this time I’m testing it before blogging about it.

I have written the following PERL program to fix the file contexts, this adds multiple lines and uses a distro_debian conditional on them so that they don’t slip into upstream use – and so that if I lose track of where each patch came from I’ll know that I can delete them in future because it only matters to Debian.

#!/usr/bin/perl
use warnings;
use strict;

open(LIST, "find . -name \"*.fc\"|xargs egrep \"^/(var.*run)|(var/lock)|(dev/shm)\"|cut -f1 -d:|uniq|") or die "Can't get file list\n";
while(<LIST>)
{
my $filename = $_;
chomp $filename;
open(my $infile, "<", $filename) or die "Can't open file $filename";
open(my $outfile, ">", $filename . ".new") or die "Can't open file ". $filename . ".new";
while(<$infile>)
{
print $outfile $_;
my $newline;
if($_ =~ /^\/var\/run/)
{
print $outfile "ifdef(`distro_debian', `\n";
$newline = $_;
$newline =~ s/^\/var//;
print $outfile $newline;
print $outfile "')\n";
}
if($_ =~ /^\/var\/lock/)
{
print $outfile "ifdef(`distro_debian', `\n";
$newline = $_;
$newline =~ s/^\/var/\/var\/run/;
print $outfile $newline;
$newline =~ s/^\/var//;
print $outfile $newline;
print $outfile "')\n";
}
if($_ =~ /^\/dev\/shm/)
{
print $outfile "ifdef(`distro_debian', `\n";
$newline = $_;
$newline =~ s/^\/dev/\/run/;
print $outfile $newline;
print $outfile "/var" . $newline;
print $outfile "')\n";
}
}
close($infile);
close($outfile);
rename $filename . ".new", $filename or die "Can't rename " . $filename . ".new to " . $filename;
}

The next policy thing that I have to work on is systemd. From a quick test it seems that systemd policy changes will be more invasive than is suitable for Squeeze. This means that someone who wants to upgrade from Squeeze to Wheezy+systemd will have to upgrade to Wheeze policy before installing systemd. I think that I will make 0.2.20100524-10 the last version in Unstable based on the 2010 release, I will now start work on packaging the latest upstream policy for Unstable.

PS I’m not much of a PERL programmer, so if anyone has suggestions for how to improve the above PERL code then please let me know. Please note however that I’m not interested in making my code look like line-noise.

[1] http://etbe.coker.com.au/2011/07/22/run-se-linux-policy/

SE Linux on /. The book SE Linux by Example has been reviewed on...
/run and SE Linux Policy Currently Debian/Unstable is going through a transition to using /run...
Context of /dev/xvc0 I have just converted a Fedora Core 5 server to...

Russell Coker (security): /run and SE Linux Policy

etbe — 2011-07-22T13:50:22+00:00

Currently Debian/Unstable is going through a transition to using /run instead of /var/run. Naturally any significant change to the filesystem layout requires matching changes to SE Linux policy. We currently have Debian bug #626720 open about this. Currently the initscripts package breaks selinux-policy-default in Debian/Unstable so that you can’t have initscripts using /run if the SE Linux policy doesn’t support it.

A patch has been suggested to the policy which uses a subst file, basically that causes the SE Linux labeling programs to treat one directory tree the same way as another. The problem with this is that it depends on a libselinux patch that is not in any yet released version of libselinux (and certainly won’t be in a Squeeze update). The upside of such a fix is that it would work for policy that I package as well as custom policy, so if someone wrote custom policy referring to /var/run it would automatically work with /run without any extra effort.

I think that the only way to do this is to just have regular expressions that deal with this in the file contexts. It’s a bit ugly and slows the relabel process down a little (probably no more than about 10%) but it will work – and work on Squeeze as well. One thing I really like to do is to have the SE Linux policy for version X of Debian work with version X+1. This makes upgrades a lot easier for the users. Ideally upgrading a server could be a process that involves separate upgrades of the kernel, the SE Linux policy, and user-space in any particular order – because upgrading everything at once almost guarantees that something will break and it may be difficult to determine the cause.

At this time I’m not sure whether I’ll add a new policy using the subs file before the release of Wheezy (the next stable release of Debian) or just keep using regular expressions. I can have the Wheezy policy depend on a new enough libselinux so it won’t be a problem in that regard (a new upstream version of libselinux with the subst feature should be released soon). In any case I need a back-port to Squeeze to use regular expressions to make an upgrade to Wheezy easier.

I used the above fragment of shell code to change “/var/run” to “/(var/)?run”, “/var/lock” to “/((var/run)|(run)|(var))/lock”, and change “/dev/shm” to “/(var/run)|(run)|(dev))/shm”. It involves a reasonable number of changes to policy (mostly for /var/run), but hopefully this will be acceptable to the release team for inclusion in the next Squeeze update as the changes are relatively simple and obvious and the size of the patch is due to it being generated code.

There is one final complication, Squeeze currently has selinux-policy-default version 2:0.2.20100524-7+squeeze1, but initscripts in Unstable breaks versions <= 2:0.2.20100524-9. So I guess I could submit a proposed version 2:0.2.20100524-9+squeeze1 to the release team to fix this. I would really like to have the Squeeze policy work with initscripts from Unstable or Wheezy.

Any suggestions for how to deal with this?

Update:

I wrote the above before testing the code, and it turned out to not work. I’ve written another post describing a better solution that I have now uploaded to Unstable. I still have to sort something out with an update for Squeeze.

New SE Linux Policy for Squeeze I have just uploaded refpolicy version 0.2.20100524-1 to Unstable. This...
An Update on DKIM Signing and SE Linux Policy In my previous post about DKIM [1] I forgot to...
Debian SSH and SE Linux I have just filed Debian bug report #556644 against the...

Dan Walsh: A new short video starring yours truly available to RHEL subscribers.

dwalsh@redhat.com — 2011-07-13T21:15:44+00:00

New SELinux Features in Red Hat Enterprise Linux 6

The Red Hat Video Team did a great job in attempting to make this old guy look good. :^)

Check it out...

Dan Walsh: New Kiosk OS posted for Fedora 15

dwalsh@redhat.com — 2011-07-12T20:24:55+00:00

Thanks to Miroslav Grepl, he has put together a working Kiosk OS for Fedora 15.

http://people.fedoraproject.org/~dwalsh/SELinux/kiosk/

Name                    Last modified      Size  
Parent Directory                             -   
kiosk.iso               12-Jul-2011 19:51  1.2G  
kiosk.ks                12-Jul-2011 19:46   11K

As you can see the ISO is quite large since we added LibreOffice.

The Kiosk OS was originally written for Fedora 13 and explained in my Blog

http://danwalsh.livejournal.com/35761.html?thread=231345

If you want to make this into a uninterruptable boot you should create the USB or DVD with the

livecd-iso-to-disk --totaltimeout 1 myiso /dev/sdb

man livecd-iso-to-disk

       --totaltimeout
           Adds a bootloader totaltimeout, which indicates how long to wait
           before booting automatically. This is used to force an automatic
           boot. This timeout cannot be canceled by the user. Units are 1/10s.

Meaning the livedvd or liveusb will boot automatically in .1 seconds and can not be stopped.

Russell Coker (security): Multiple Filesystems for Security

etbe — 2011-07-08T13:27:49+00:00

There is always been an ongoing debate about how to assign disk space into multiple partitions. I think that nowadays the best thing to do is to assign about 10G for the root filesystem for every desktop and server system because 10G is a small fraction of the disk space available (even the smallest laptops seem to all have disks larger than 100G nowadays). Even if 10G turns out not to be enough using separate filesystems for /var or /usr provides little benefit now that it’s easy to resize the root filesystem with LVM – and a separate /usr is known to be broken [1].

In a discussion on a private mailing list there was a suggestion that multiple filesystems should be used for security.

DoS Attacks

There are some minor security benefits in having multiple filesystems. If a critical program will fail when there is no free disk space then allowing an unprivileged process to use up all the space on that filesystem is a minor security issue, so having unprivileged processes not being permitted to write to important filesystems is a benefit. But most failures of this type are merely DoS attacks which usually aren’t a big deal – if you can control a local process there are usually lots of other ways of DoSing a system.

Links

Links have been the cause of many security issues in Unix over the years. Using different filesystems for different tasks can prevent the use of hard links in attacks aimed at exploiting race conditions. But even if you prevent hard links there are similar issues with symbolic links. SE Linux is one of many security improvements for Linux which allow restrictions on the creation of hard links. SE Linux also allows restricting the ability of processes to follow symbolic links, so a privileged process can be denied access to follow a sym-link that was created by an unprivileged process.

NFS

The subtree_check option in /etc/exports causes the NFS server to verify that file access is in the correct subtree. So if you export only one subdirectory of a filesystem to a given server then hostile code on that server (or on a network device which impersonates that server) can’t access other subdirectories. This option is documented as having performance implications and working best for filesystems that are mostly read-only, for this reason it’s turned off by default in recent versions of the NFS utilities.

So if you want to NFS export /home then it’s probably a good idea to have /home be on a separate filesystem to prevent attacks on the root filesystem. But of the systems with significant use of /home (IE anything other than accounts used solely for “su -“) most of them have a separate filesystem for /home anyway so this shouldn’t be an issue.

SE Linux

When mounting filesystems with SE Linux there is a “context=” mount option that allows specifying the context for all files on the filesystem. This can save a small amount of storage space for XATTRs and theoretically improve performance (although the difference is unlikely to show up on benchmarks for anything other than fsck). Generally the context mount option is only used for a filesystem that has a huge number of files with the same context, such as a mail spool that uses Maildir, Cyrus, or any of the other formats that involve one file per message. But again such data is generally stored on a separate filesystem for other reasons anyway.

I found one interesting corner case in regard to SE Linux systems mounting files from an NFS server. When an NFS server exports multiple subdirectories of a filesystem mounted on /foo then if one NFS client running SE Linux is to mount two subdirectories of /foo with different contexts then the second mount attempt will give the error “an incorrect mount option was specified”. This is because as of kernel 2.6.18 by default it’s not permitted to mount parts of the same filesystem with different mount options. The option “nosharecache” allows you to use different mount options, but does apparently permit some undesirable behavior in the case of hard links that cross between the subtrees. Thanks to Eric Paris for the tip about nosharecache.

The best example I can think of for which you might want context mount options that differ among files that are used for the same purpose on an NFS mount is a web server which has data files and CGI-BIN scripts. So it seems that a SE Linux web server that mounts it’s data over NFS and is at risk of having hard links between the CGI-BIN directory and the data directory is a corner case in which multiple filesystems is required for security. This seems to be a very unlikely case.

Conclusion

Servers that are deployed in the real world are complex enough that there are always systems with some unusual corner cases demanding configuration choices that aren’t expected. There are some real corner cases for SE Linux where multiple filesystems are compelled for security or for a combination of security and best performance.

But I wouldn’t make a generic recommendation of using lots of filesystems for security. I think that the people who encounter the strange corner cases can usually work out that they need to do something different. So a small number of filesystems seems like a good general aim that doesn’t conflict with security.

[1] http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

Dan Walsh: Fun with sVirt.

dwalsh@redhat.com — 2011-07-07T22:14:35+00:00

I have been in Washington DC for the last few days talking about SELinux and sVirt, Secure Virtualization.

sVirt is the combining of SELinux with kvm/qemu virtualization. The libvirt daemon launches virtual guests in Red Hat operating systems. Before an virtual machine is started libvirt picks a random MCS label with two categories, like s0:c1,c2 and then labels all of the virtual machines content as svirt_image_t:s0:c1,c2. Then it executes qemu with the label svirt_t:c0:c1,c2.

One of the questions on sVirt I have been asked is how can I test out the sVirt policy, to make sure it works?

I thought about it and I came up with an easy way that someone can play with it.

One of the major goals of a hacker is to get a root shell on the host, lets see what you can do with the root shell running as svirt_t.

Note: the unconfined_t user type is allowed to transition to svirt_t in Fedora 14-16 and RHEL6 I believe.

In order to test the svirt_t, we need a program to run, I copied /bin/sh to /bin/svirt.

# cp /bin/sh /bin/svirt

The policy requires that the entry point for svirt_t must be labeled qemu_exec_t.

# chcon -t qemu_exec_t /bin/svirt

Now I use the runcon command to force a transition from unconfined_t to svirt and pick out an MCS label s0:c1,c2 to run with the svirt shell.

# runcon -t svirt_t -l s0:c1,c2 /bin/svirt
svirt: /root/.bashrc: Permission denied
# id
svirt: child setpgid (6962 to 6962): Permission denied
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=unconfined_u:unconfined_r:svirt_t:s0:c1,c2
First the shell tried to read /root/.bashrc and was denied. because svirt_t is not allowed to read the admin_home_t label. The shell attempts to setpgid for every command that is executed which SELinux denies svirt_t and prints an error to the screen. I have removed these errors from the blog just for clarity.
# ping 4.2.2.2
svirt: ping: command not found
# cat /etc/shadow
cat: /etc/shadow: Permission denied
# touch /tmp/svirt
# ls -lZ /tmp/svirt
-rw-r--r--. root root unconfined_u:object_r:svirt_tmp_t:s0:c1,c2 /tmp/svirt
Note Notice the touch succeeded, allowing me to create a file in the /tmp directory labeled svirt_tmp_t:s0:c0,c2
# ^D

Now I exit this shell and start another svirt shell with a slightly different MCS label s0:c1,c3

# runcon -t svirt_t -l s0:c1,c3 /bin/svirt
svirt: /root/.bashrc: Permission denied
# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=unconfined_u:unconfined_r:svirt_t:s0:c1,c3
# touch /tmp/svirt
touch: cannot touch `/tmp/svirt': Permission denied

Note: This svirt shell is denied the ability to use the previously created /tmp/svirt file since this file has a label s0:c1,c2 but this svirt shell is running as s0:c1,c3. This would simulate one svirt guest process attacking another svirt_t process.

Have fun with this and see what svirt can do. If you find what you believe to be a vulnerability please report it in bugzilla. If you build a test script with this, we would love to use it.

You will fill your /var/log/audit/audit.log file with audit messages and setroubleshoot will not be happy, but it is pretty good test.

Dan Walsh: Follow up to #7 Does an SELinux Audit Log message always mean something was blocked?

dwalsh@redhat.com — 2011-06-28T11:43:39+00:00

In my previous blog

10 things you probably did not know about SELinux.. #7

I stated that one of the times you can get a syscall to succeed even though AVC's were generated was:

3. An AVC was generated but the syscall still succeeded by going down a different code path within the kernel. This is not that common.

Eric Paris pointed out to me in an email and example of this:

(People have a) " fundemental misconception is the belief that there is a 1-1 mapping between a syscall and an selinux permissions check. SELinux is NOT a syscall filter. We check the security state between objects (aka between a task and a file, or a task and a socket, or a task and task) and the result of that check may or may not cause the intended purpose of the request syscall which triggered this check to fail.

A great example of a syscall which is likely to generate AVCs but still give success=yes is execve(). On execve SELinux will check the permissions between the new task and any file descriptors passed from the parent to the child. Notice the check is not about the syscall, execve(), but between the new task and the file descriptors. If the new task is not allowed to access one of the passed file descriptors we will generate an AVC, and will close the fd and open /dev/null in it's place. This is an example of an alternate code path. The syscall is still going to succeed since we will have resolved the security violation that caused the AVC. It's not common, but other such places exist in the kernel, place where we are able to resolve the security issue by doing some other operation and thus the syscall does not need to fail."

Dan Walsh: 10 things you probably did not know about SELinux.. #7

dwalsh@redhat.com — 2011-06-24T13:42:36+00:00

#7 Does an SELinux Audit Log message always mean something was blocked? NO

First off lets get rid of a misconception. An SELinux AVC message consist of a single message in the audit log.

This is false.

SELinux messages in the Audit log usually consist of more then one record, and they don't even need to contain an AVC record.

SELinux is all about preventing syscalls, so if something gets denied you will usually see an SELinux message describing the AVC, as well as the SYSCALL. If you have full auditing turned on, or the kernel has gathered path information, you could also get a PATH record as part of the overall audit record.

The way to view all the records within an AVC message is to use the ausearch -m avc command.

If you look at the SYSCALL record you will see a Name/Value pair with the name "success". This field indicates whether they SYSCALL record actually succeeded or failed. "success=yes" indicates the syscall was successful.

I can think of 4 different situations where a SELinux message is generated and the SYSCALL record returns success=yes.

The system is in permissive, meaning AVC's are recorded but not enforced.

> getenforce
Permissive

The process that caused the domain is a permissive domain (Latest Fedoras/RHEL6 only). The AVC for this process type is not enforced.

> seinfo --permissive |grep SOURCETYPE

An AVC was generated but the syscall still succeeded by going down a different code path within the kernel. This is not that common.
An auditallow record was added to the policy. auditallow says to the kernel, generate an audit SYSCALL message any time this access is granted. Currently we do this with load_policy and setting booleans, setenforce.

type=SYSCALL msg=audit(06/23/2011 13:33:58.044:280) : arch=x86_64 syscall=write success=yes exit=1 a0=3 a1=7fff406c5ce0 a2=1 a3=0 items=0 ppid=4408 pid=4546 auid=dwalsh uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=4 comm=setenforce exe=/usr/sbin/setenforce subj=staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 key=(null) type=MAC_STATUS msg=audit(06/23/2011 13:33:58.044:280) : enforcing=1 old_enforcing=0 auid=dwalsh ses=4

Thomas Biege (Security): SUSE Manager Security Update

Thomas (noreply@blogger.com) — 2011-06-21T01:38:04+00:00

Last Friday we released a security update for SUSE Manager. It eliminates four vulnerabilities which I will describe in detail here:

CSRF (CVE-2009-4139): This is the most dangerous issue fixed by this update. It was found during a penetration-test executed by me before we released the SUSE Manager. You may wonder why we released the fix after the "gold master" (GM) and why it has a CVE-ID from 2009. Red Hat was informed about this issue in 2009 already (by another person) and after some back and forth we decided to release it together with Red Hat and not earlier. But not only the release date was coordinated, we also coordinate fixing and testing.
The default SSL ciphersuite configuration that comes with our apache2 package (this also affects the SM proxy) was made up to support as much and as old client as possible. This results in a config that is insecure because it support "export ciphers", SSLv2, short keys, etc. If you install this update before you configured your SM you will have a up-to-date and secure config. Use sslscan to verify your setup. If it is still insecure go to /etc/apache2/ssl-global.conf and change it to something like:
ssl_protocols TLSv1
ssl_ciphers ALL:!aNULL:!eNULL:!SSLv2:!LOW:!EXP:!MD5:@STRENGTH
Open Redirect (CVE-2011-1594): A hidden field named "url_bounce" allows HTTP redirects and therefore phishing attacks. Found during penetration-test, released after GM because it was too minor to hold release.
XML remote denial of service (CVE-2011-1755): jabber2 server can be dos'ed ("billion laughs attack"), not found by us.

kostenloser Counter

Dan Walsh: SELinux Policy RPM in Rawhide/F16 includes prebuilt policy file.

dwalsh@redhat.com — 2011-06-16T17:27:16+00:00

The selinux-policy-TYPE packages has always rebuilt the policy in their post install. We do this in order to merge any customizations to the policy that an administrator might have made. The selinux policy rpm package also needs to rebuild the policy if any policies were installed by other rpms or by the administrator.

Over time as the size of policy has grown and gotten more complex, the installation procedure has required more memory and more time. We have seen stats stating during installations, one of the biggest memory hogs was the selinux-policy-targeted package.

Over the last couple of weeks, I decided to re-examine the situation.

The selinux-policy-TYPE packages will now ship with a pre-built policy package and will only rebuild the policy iff the existing policy has been customized.

The following test shows a 4 times speedup on installing the package 48 Seconds -> 12 Seconds. And max Memory Usage from 38 M to 6 Meg.

Modified:
# time -v rpm -Uhv /home/devel/dwalsh/sources/RPMS/noarch/selinux-policy-targeted-3.9.16-29.1.fc16.noarch.rpm --force
Preparing...                ########################################### [100%]
   1:selinux-policy-targeted########################################### [100%]
    Command being timed: "rpm -Uhv /home/devel/dwalsh/sources/RPMS/noarch/selinux-policy-targeted-3.9.16-29.1.fc16.noarch.rpm --force"
<snip>
    Elapsed (wall clock) time (h:mm:ss or m:ss): 0:48.11
<snip>
    Maximum resident set size (kbytes): 377608
<snip>

Unmodified:
# time -v rpm -Uhv /home/devel/dwalsh/sources/RPMS/noarch/selinux-policy-targeted-3.9.16-29.1.fc16.noarch.rpm --force
Preparing...                ########################################### [100%]
   1:selinux-policy-targeted########################################### [100%]
    Command being timed: "rpm -Uhv /home/devel/dwalsh/sources/RPMS/noarch/selinux-policy-targeted-3.9.16-29.1.fc16.noarch.rpm --force"
<snip>
    Elapsed (wall clock) time (h:mm:ss or m:ss): 0:12.32
<snip>
    Maximum resident set size (kbytes): 60112
<snip>

You will only see this improvement on a fresh install. And should continue to see it on all updates, although updates can still do a partial relabel after install.

If you are doing an update and would like to see the improvement, you can do the following.

# setenforce 0
# rm -rf /etc/selinux/targeted
# yum -y reinstall selinux-policy selinux-policy-targeted
# restorecon -R -v /etc/selinux/targeted
# setenforce 1

Then you would be seen as a fresh install.

Try it out.

James Morris: Linux Security Summit 2011 – Schedule Published

jamesm — 2011-06-15T15:33:02+00:00

For those that didn’t catch the email announcement, the schedule for the 2011 Linux Security Summit is now published.

The format of the conference is refereed talk sessions, followed by in-depth roundtable discussions.

Here’s a summary of the programme:

Refereed talks:

“Smack is Alive and Well”
Casey Schaufler

“MeeGo Security Update”
Ryan Ware, Intel

“An Overview of the Linux Integrity Subsystem: Use Cases and Demonstration”
David Safford and Mimi Zohar, IBM

“Digital Signature support for IMA/EVM”
Dmitry Kasatkin and Ryan Ware, Intel

“Protecting the Filesystem Integrity of a Fedora 15 Virtual Machine from Offline Attacks using IMA/EVM”
Peter Kruus, The Johns Hopkins University Applied Physics Laboratory

“Efficient, TPM-free system integrity checking with device mapper: dm-verity”
Will Drewry and Mandeep Baines, Google

Roundtable discussions:

Kernel Hardening
Lead by Kees Cook, Canonical and Will Drewry, Google

LSM Architecture
Lead by Kees Cook, Canonical and Casey Schaufler

See the full schedule for more detail.

Attendance is open to all registered attendees of the Linux Plumbers Conference. Early-bird registration is available for LPC until the end of today (US time).

Dan Walsh: 10 things you probably did not know about SELinux.. #6

dwalsh@redhat.com — 2011-06-10T18:52:19+00:00

#6 How did those SELinux labels get there?

SELinux labels are placed on disk during the installation by a combination of Anaconda and rpm. Anaconda actually includes the latest /etc/selinux/targeted/files/file_context and /etc/selinux/targeted/policy/policy.26 in its initrd. When anaconda starts rpm, rpm reads this file and proceeds to place the labels on disk. RPM has SELinux awareness built into it and asks the kernel to place the default label on the disk for every object that it creates from its payload. If an rpm post install script runs during the install, the labels are created using the standard process labelling described below. Any file system objects created by Anaconda before loading the policy into the kernel will be relabelled by Anaconda using restorecon.

Any file system objects created by the post install scripts, or during boot, or by any process from then moving forward will create the file via one of the following three rules.

The object will get the label of the parent directory.
- Files/Directories created in /etc, which is labelled etc_t, will get labelled etc_t by default.
File transition rules can be written into policy. File transition rules take into account the label of the process creating the file as well as the parent directory. For example I can write a rule that says if NetworkManager_t creates a file in a directory labelled etc_t then this file will be labelled net_conf_t
- filetrans_pattern(NetworkManager_t, etc_t, net_conf_t, file)
- When NetworkManager creates the /etc/resolv.conf file it gets labelled net_conf_f rather then etc_t.
- Since you can only have one combination of ProcessLabel/DirectoryLabel/ObjectClass, you can not currently write a rule for a process to create two different labels within the same directory.
The last way is to build SELinux awareness within an application.
- Applications can be programmed to ask the kernel to create a file system object with a particular label.
  - rpm, udev, passwd are examples of applications that request the kernel to label the object at creation time.
- Applications can attempt to change a label from one label to another.
  - restorecon, udev, restorecond, chcon are examples of applications that modify labels.

In Fedora 16 we are introducing a new concept which we are calling File Name Transitions. These will allow policy writers to take into account the actual file name (Not path) at file creation time, giving us the ability to clear up some common bugs users have seen with SELinux.

Read about it here and if you are running Fedora 16/Rawhide try it out...

https://fedoraproject.org/wiki/Features/SELinuxFileNameTransition

Thomas Biege (Security): SAD 4: Security Day

Thomas (noreply@blogger.com) — 2011-05-24T12:14:00+00:00

Three weeks ago the SUSE Studio team had its first "Security Day" to fix the possible security vulnerabilities found by ror-sec-scanner. (a Rails static code analyzer)
The team eliminated:

161 false positives
28 real bugs

Thank you folks! :-)

Note: Earlier this year another team consolidated its forces to fix potential security problems in their code and reduced the number of bugs per KLOC to 0.

I hope we can have a "Security Day" prior every new release.

kostenloser Counter

James Morris: Linux Security Summit 2011 – CFP closes in one week.

jamesm — 2011-05-20T22:48:01+00:00

We’ve had a couple of queries about what to submit for the Linux Security Summit CFP.

Proposals should be plain text abstracts up to 150 words in length, and emailed to the program committee: lss-pc (_at_) ext.namei.org

Also see the CFP section on the wiki.

KaiGai Kohei: [OSS/Linux] Leaky VIEW まとめ

kaigai — 2011-05-15T13:40:03+00:00

SELinuxとは関係のない、RDBMSでのセキュリティのお話。

利用者に対して、テーブルに対する直接のアクセス権を与えず、特定のビューを通してだけアクセスを許可するのは、行レベルのアクセス制御でよく使われるテクニックである。

つまり、ビューは不可視であるタプルをフィルタリングする役割を持つ。

しかし、これで万全かというと、そうではない。

クエリ最適化を上手く利用することで、利用者が見えないはずのタプルを参照する事は可能である。

以下の例を見て頂きたい。

postgres=# CREATE TABLE T1 (id int, name text);
CREATE TABLE
postgres=# CREATE TABLE T2 (id int, cred text);
CREATE TABLE
postgres=# INSERT INTO t1 VALUES (1, 'coke'), (2, 'soda'),
                                 (3, 'juice'), (4, 'fanta');
INSERT 0 4
postgres=# INSERT INTO t2 VALUES (1, 'public'), (2, 'hidden'),
                                 (3, 'hidden'), (4, 'public');
INSERT 0 4
postgres=# CREATE VIEW v1 AS SELECT * FROM t1 NATURAL JOIN t2
                                      WHERE t2.cred = 'public';
CREATE VIEW
postgres=# SELECT * FROM v1;
 id | name  |  cred
----+-------+--------
  1 | coke  | public
  4 | fanta | public
(2 rows)

postgres=# GRANT SELECT ON v1 TO alice;
GRANT

ビュー v1 は、テーブル t1 と t2 を JOINし、ここでは t2.cred = 'public' が行レベルのセキュリティポリシー、すなわち、フィルタリング対象の行を定めるものとする。

ユーザ alice は t1 と t2 へのアクセス権を持っていないため、ビュー v1 を通してしか、これらの情報にアクセスできないはずである。

だがしかし、以下のクエリの実行結果を見てもらいたい。

postgres=> SELECT getpgusername();
 getpgusername
---------------
 alice
(1 row)

postgres=> SELECT * FROM t1;
ERROR:  permission denied for relation t1
postgres=> SELECT * FROM t2;
ERROR:  permission denied for relation t2
postgres=> SELECT * FROM v1;
 id | name  |  cred
----+-------+--------
  1 | coke  | public
  4 | fanta | public
(2 rows)

上記の結果は想定通りだろう。

では、続いて、WHERE句にユーザ定義関数を付加する。

この関数は、常に true を返すが、引数を利用者のコンソールに出力する。

postgres=> CREATE OR REPLACE FUNCTION f_leak(text)
               RETURNS bool LANGUAGE 'plpgsql'
               AS 'BEGIN
                       raise notice ''f_lead: (%)'', $1;
                       RETURN true;
                   END';
CREATE FUNCTION
postgres=> SELECT * FROM v1 WHERE f_leak(name);
NOTICE:  f_lead: (coke)
NOTICE:  f_lead: (soda)
NOTICE:  f_lead: (juice)
NOTICE:  f_lead: (fanta)
 id | name  |  cred
----+-------+--------
  1 | coke  | public
  4 | fanta | public
(2 rows)

結果セットは２行だが、利用者コンソールには見えてはならないはずのタプルの内容が出力されている。

その理由はEXPLAIN分の出力を見ると明らかである。

postgres=> EXPLAIN SELECT * FROM v1 WHERE f_leak(name);
                           QUERY PLAN
----------------------------------------------------------------
 Hash Join  (cost=25.45..356.91 rows=12 width=68)
   Hash Cond: (t1.id = t2.id)
   ->  Seq Scan on t1  (cost=0.00..329.80 rows=410 width=36)
         Filter: f_leak(name)
   ->  Hash  (cost=25.38..25.38 rows=6 width=36)
         ->  Seq Scan on t2  (cost=0.00..25.38 rows=6 width=36)
               Filter: (cred = 'public'::text)
(7 rows)

f_leak()関数を探してみると、Join-Loopの内側で t1 テーブルを読み出す際のフィルタリング条件として実行されている事がわかる。

これは、f_leak()の引数が t1 由来のデータだけを参照しているため、Joinすべき行数を減らすために、本来実行されるべき位置（t1.id = t2.id を評価した後）からオプティマイザによって移動させられた事による。

とは言え、この手の最適化を行わなければビューを介したアクセスは極端に性能が悪くなるはずなので、問題は PostgreSQL に限った話ではないと思われる。

例えば、100万件のタプルを持つテーブルでID列にインデックスが張られており、処理コストの比較的高い f_policy() 関数によってフィルタリングを行うビューを介してアクセスするとする。その場合、ビューの外から ID = 1234 という条件が来た場合に常に全件スキャンが走るようなら、泣ける。

手元にOracleの環境がある友人に試してもらったところ、同様に、見えないはずのタプルの内容を出力できるそうな。

なお、PostgreSQLには、セキュリティポリシーの適用されている t2 の内容を見る方法もある。*1

以下のような関数を定義する。ポイントは COST=0.0001 の部分。

postgres=> CREATE OR REPLACE FUNCTION f_leak(text)
               RETURNS bool LANGUAGE 'plpgsql'
               COST 0.0001
               AS 'BEGIN
                       raise notice ''f_lead: (%)'', $1;
                       RETURN true;
                   END';
CREATE FUNCTION

今度は f_leak() 関数で t2 の情報を参照するようにすると、同様にフィルタリングされているはずの行の内容が出力される。

postgres=> SELECT * FROM v1 WHERE f_leak(cred);
NOTICE:  f_lead: (public)
NOTICE:  f_lead: (hidden)
NOTICE:  f_lead: (hidden)
NOTICE:  f_lead: (public)
 id | name  |  cred
----+-------+--------
  1 | coke  | public
  4 | fanta | public
(2 rows)

EXPLAIN文の結果

postgres=> EXPLAIN SELECT * FROM v1 WHERE f_leak(cred);
                            QUERY PLAN
------------------------------------------------------------------
 Hash Join  (cost=25.40..52.43 rows=12 width=68)
   Hash Cond: (t1.id = t2.id)
   ->  Seq Scan on t1  (cost=0.00..22.30 rows=1230 width=36)
   ->  Hash  (cost=25.38..25.38 rows=2 width=36)
         ->  Seq Scan on t2  (cost=0.00..25.38 rows=2 width=36)
               Filter: (f_leak(cred) AND (cred = 'public'::text))
(6 rows)

今度は、f_leak()がt2のScan-Loopに結合されているが、注目すべきはその順序。

f_leak()のコスト値を低く設定したために、複数のフィルタリング条件がScan-Loopに結合している場合、f_leak()が cred = 'public' よりも優先されている。

後者のシナリオは、何もJoinを伴わない場合でも実行可能である。

この問題は、既に開発者の中では既知の問題で、利用者から特定のタプルを不可視にする目的でビューを使うべきでない事が明記されている。

http://www.postgresql.jp/document/current/html/rules-privileges.html

5/18にオタワで開催される PostgreSQL Developer Meeting では、この問題を議論するつもりである。

一応、解決策の腹案は持っているが、そこまで踏み込まないにしても、先ずはこの辺のシナリオが『解決すべき課題である』というコンセンサス形成あたりを目標としたい。

*1：PostgreSQL固有というのは、他のRDBMSでユーザ定義関数のコストを指定する手段があるかどうか不明のため。

James Morris: Linux Security Summit 2011 – CFP reminder: 2 weeks!

jamesm — 2011-05-13T02:29:13+00:00

Calling all Linux security folk!

Just a reminder that the CFP for the 2011 Linux Security Summit closes on the 27th of May — two weeks away. Please get your submissions in soon.

Note again that we are co-located with the Linux Plumbers Conference in Santa Rosa, and that all Security Summit attendees, including speakers, will need to register for Plumbers. Earlybird registration is available until 31st May.

Trivia question: which Alfred Hitchcock film was shot on location in Santa Rosa in 1943?

(Hint: click on the image)

Thomas Biege (Security): SAD 3: At the Beginning there was a Thought

Thomas (noreply@blogger.com) — 2011-05-04T02:43:04+00:00

Last night I stumbled over some old docs of the Security Review Board. More than 5 years ago T.G. puts much effort in enhancing the development processes to create more secure products. I never saw numbers about that project to compare pre and past states of the products. Unfortunately she left a few years later but AFAIK some of her work is still in use today.

Today I browsed Google Docs and found a 2 year old presentation I wrote during a train journey from Nuremberg to my home town. I never want to show the slides to other people I just brainstormed about how we could integrate security into our products. Let me show you some slides here because they describe where we were 2-3 years ago. As I said I forgot the slides but funnily various things from them are real now or are on my TODO list.

Slide 1: Where we are.
- We have four different sources of code
-- 1.) Mainly FLOSS
-- 2.) In-house development
-- 3.) 3rd-party commercial free binary code (like RealPlayer, acroread, etc.)
-- 4.) 3rd-party code developed by contractors
- We review FLOSS code but there is too much and we have not much
influence on the developers beside sending patches upstream
- We have much influence on our own developers but we have to develop
a better security awareness as well as technical knowledge
- We have no influence on the 3rd-party free binary code and just need
to trust it.
- Code developed by contractors can be reviewed by us

Today source 1. is still the main source for code contributions, the in-house development (2.) increases a lot over the past years, we try to reduce (openSUSE is completely free of them, see the NonFree repo) the number of binary-only packages (3.), I am not aware of current contributions from source 4.
In the past we provided workshops for secure programming (C, C++, Shell, Perl, Ruby on Rails, Web-security in general).

Slide 2: Where others are.
- Microsoft
-- founder of the Secure Software development Life Cycle (SDL)
-- Separate, specialized teams
-- Own and optimized tools for stress-testing (fuzzing) as well as code analysis
-- See BSIMM study [1], [2]
- Cisco
-- CMSDL
- Adobe
-- See BSIMM study [1], [2]
- Google
-- specialists/teams working on research topics and develop tools as well as guidelines
-- See BSIMM study [1], [2]
- Red Hat
-- Specialized teams/persons
-- Much more people working on security
-- Better contact to developers?
-- Only re-active not pro-active AFAIK

Currently we are introducing secure SDLC techniques and testing tools for our in-house products. Teams are planned to grow.

Slide 3: We need to catch up because...
- Releasing patches for avoidable bugs is a big waste of money and time
- Customers critically watch software vendor's product quality and security vulnerabilities
- These observations play a big role in buying new products or continuing support contracts because installing patches costs the customer money (see study "The Total Cost of Security Patch Management") and therefore increases the cost of the product.

Slide 4: What we can do now!
- Increase awareness by:
-- Showing consequences by providing examples of security problems in our code
- Increase code quality by:
-- Online teaching of security best practice rules for common programming languages like C, C++, C# and Java (see CERT's SDI)
-- Adopt secure SDLC processes for our in-house development
-- Provide a standard development environment that includes easy-to-use code analysis tools for our programmers
-- Teach how to use this tools.
-- Do more sophisticated code analysis

We are on the right track.

Slide 5: What we need to do in the future.
- Develop/acquire better tools for code analysis, fuzzing, etc.
- Incrementally refine our coding standards
- Have separate teams for handling bugs (response team), create new tools and keep track of current software security development (research team), a team for shepherding code development (mentor team) and a pen-testing team to verify in-house, FLOSS code
- Being part of secure development initiatives/groups/workshops

Well different teams is a dream that will never become true, but we will try to reach our goals using another way.

Slide 6: Where we should be.

kostenloser Counter

Russell Coker (security): What is Valid SE Linux Policy?

etbe — 2011-04-28T21:00:18+00:00

Guido Trentalancia started an interesting discussion on the SE Linux policy development list about how to manage the evolution of the policy [1].

The Problem

The SE Linux policy is the set of rules that determine what access is granted. It assigns types to files and domains to processes and has a set of rules that specify all the permitted interactions between processes and files (among many other things). The policy evolves over time to match the requirements of programs (applications and daemons). As a program evolves the things that it does will change and the SE Linux policy will tend to evolve to permit the set of all operations that were requested by all versions because people only complain when things stop working not when excessive privilege is granted. So we need to periodically remove old allow rules from the policy.

One difficulty in this regard is the fact that multiple versions of programs are often available for use at the same time. Debian in particular has a good history of providing separate packages for the old and new versions of programs such as Apache to meet the needs of users who want the tried and tested version and of users who want the newer version with better performance, more features, better documentation, or something else good. There is also a demand to have the same policy work with multiple versions of a distribution without excessive effort. Finally all the distributions that have SE Linux support have different people deciding when the new version of a daemon is ready for inclusion and therefore there is a need to support multiple versions for multiple distributions. So support for older versions of daemons can’t be removed easily.

One of the things I do to make these things a little easier to manage is to put ifdef(`distro_debian', ` before any Debian specific bits of policy. When policy is conditional and only used in Debian I can freely remove it at any future time if Debian works well without it. Also it doesn’t matter if such Debian specific policy allows access that is not needed or desired in other distributions, the only down-side to this is that sometimes other distributions need to repeat work that I did, they determine what access is needed for their configuration and discover that it was already enabled for Debian.

What is Valid Policy?

We went to only have “Valid Policy” (as described by Christopher J. PeBenito), so the challenge is determining what is Valid Policy.

It seems to me that there are three type of access granted by valid policy (it is debatable whether type #3 is valid):

Access that is needed for an application to perform it’s minimal designed task.
Access that is needed for the application to perform all the optional configurations, EG an ftpd running from inetd or as a daemon, and daemons like http server being granted access to ssl keys or not.
Access that is needed to perform all the operations the application requests, but which the application doesn’t require or shouldn’t require if it worked correctly.

Some common operations that aren’t required include opening utmp for write, searching /root, and many other relatively innocuous access attempts which don’t affect the program operation if they are denied. There are also many things such as writing temporary files to /root that don’t seem unusual if the application developer is not considering SE Linux (but which are often considered bad practice anyway). Some of these things (like using /root for stuff that belongs in /var/lib) have the potential to break things (for the daemon or for other system processes) even if you don’t consider SE Linux.

How to deal with those types:

In most cases this can be determined without too much effort. For example a web server needs to listen on port 80 and read files and directories that relate to data. When writing policy I can write a lot of the allow rules without even testing the application because I know from the design what it will do. A large part of the other access is obvious in a “I can’t believe I didn’t realise it would need this” sense.
The main question here is whether we have booleans (settings which can be tuned at run-time by the sysadmin which determine how the policy works) to specify which optional tasks or whether we allow all access for optional configurations by default. The secondary question is when certain unusual corner cases should be not supported at all such that the people who do such unusual corner cases need to use audit2allow to generate local policy to allow their operations.
Sometimes we have to allow things that we really don’t like. Even when we write policy to allow a daemon to do unusual things (such as using /root instead of /var/lib) it’s still a lot better than running without SE Linux. Also SE Linux policy to allow such obviously broken things stands out and is a constant reminder that the daemon needs fixing, this is better than allowing symptoms of broken design to be forgotten.

How to Improve the Situation

We could have comments in the policy source for everything that is in category 3. If the comments had a fixed format so that a recursive grep could find them all then it would allow us to more easily remove the gross things from the policy at a later date.

But it seems to me that the main problem is a lack of people working on this. I am not aware of any people actively testing Debian policy for excessive privilege in regard to such issues.

[1] http://oss.tresys.com/pipermail/refpolicy/2011-March/004115.html

Dan Walsh: 10 things you probably did not know about SELinux.. #5

dwalsh@redhat.com — 2011-04-14T15:10:55+00:00

#5 How do I add new file systems/disks to an SELinux machine?

Lets examine three use cases:

1: You just got back from Best Buy with a brand new 100 Gig Disk that you want to mount on /home and store your homedirs. You add the disk mount to /etc/fstab, mount it untar your entire backed up directory to the disk. Now you attempt to login with a confined user. Login fails, and the audit logs fill up with AVC messages concerning file_t. Even without confined logins, applications like sshd can't read the ~/.ssh directory and Apache can no longer read the ~/public_html directory.

SELinux reporting errors with the type file_t indicates that the file/dir has no label. SELinux has no idea what content is stored in a file without a label, therfore the kernel denies confined applications access to these files. Ordinarily when I have seen random files all over the disk labelled file_t, I have told the user to relabel the entire machine. touch /.autorelabel; reboot In this case we know the user just added a disk, so all he needs to do is run restorecon on the disk. restorecon -R -v /home. The restorecon command will put the default labels on the entire disk. This also works on disks that you moved from one machine to another, especially important if the machine had SELinux disabled.

2. You add a new lvm mount that you want to store all of your postgresql database directory on. You create a new directory tree /data/postgresqldb and mount the disk here and mount the directory on /data/pgsql.    You are an advanced SELinux user so you know you need to put labels down, you run "restorecon -R -v /data/pgsql". Now you service postgresql start, and POW it blows up. The setroubleshoot star shows up and you read the analysys. The analysys tells you that postgresql is trying to access a file in a directory labeled default_t. Newly created directories in / are labelled default_t. Just like file_t, the SELinux kernel does not know what content is stored in a file/directory labeled default_t, so all confined applications are blocked from reading default_t files/directories. The setroubleshoot analysis also tells you you need to put a label on the directory, and choose from a list of labels including postgresql_db_t. You figure that looks good and you follow the instructions,

# semanage fcontext -a -t postgresql_db_t '/data/pgsql(/.*)?'
# restorecon -R -v /data/pgsql

The semanage command tells the SELinux system what the default label for this directory will be going forward. The restorecon command actually puts the labels on the disk.

Now you service postgresql start, and POW it blows up again. At this point you are real unhappy with SELinux. This time the AVC's indicate that postgresql_t is not able to search through the /data directory which is labelled default_t. Your labelling was added at a directory a level below what you needed.

# semanage fcontext -d '/data/pgsql(/.*)?'
# semanage fcontext -a -t postgresql_db_t '/data(/.*)?'
# restorecon -R -v /data

I am sorry we blew it on this, but hopefully this example will help you understand a little of what SELinux is doing.

# service postgresql start

It works!!!

Now you can take the pins out of the voodoo doll of me.

NOTE: If you were to store the postgresql database in a subdirectory of a normal file system directory, DO NOT change the label of that directory.
For example /home/postgesql.

# semanage fcontext -a -t postgresql_db_t '/home(/.*)?'
# restorecon -R -v /home

Would thoroughly screw up your machine. In this case it is better to do

# semanage fcontext -a -t postgresql_db_t '/home/pgsql(/.*)?'
# restorecon -R -v /home/pgsql
Then add allow rules for posqgresql_t to search through home_root_t using

#grep postgresql_t /var/log/audit/audit.log | audit2allow -M mypostgresql
# semodule -i mypostgresql.pp
3. You want to share Apache data on an NFS share using multiple httpd hosts.   You mount the remove nfs directory at /var/www/.

# service httpd start
It blows up permission denied. This time setroubleshoot is complaining about httpd_t trying to read nfs_t. The analysis tells you that you can allow httpd_t to read all nfs_t by setting a couple of different booleans.

httpd_use_nfs or use_nfs_home_dirs

Since you are not using nfs for your home directories, it would be a bad idea from a security point of view to turn this boolean on.  The use_nfs_home_dirs boolean allows any confined domains that need access to home directory content to get access to all files labeled nfs_t.

Turning on httpd_use_nfs will solve your problem.
But what if you had other nfs shares mounted which you did not want to grant access to Apache?

The third option would be to use a mount option.

# mount -o context="system_u:object_r:httpd_sys_content_t:s0" REMOTEHOST:/var/www /var/www

This command tells the SELinux kernel to treat all content in this file system as httpd_sys_content_t. httpd_t will be allowed to access the content mounted as httpd_sys_content_t, but the kernel will still deny httpd_t access to other NFS file systems mounted on the system.

James Morris: Linux Security Summit 2011 (Santa Rosa) – CFP Open

jamesm — 2011-04-04T09:07:19+00:00

The 2011 Linux Security Summit has been announced, and the CFP is open until the 27th of May.

Following last year’s successful event in Boston, the 2011 Linux Security Summit (LSS2011) will be held on the 8th of September this year in conjunction with the Linux Plumbers Conference.

The program committee is looking for submissions from developers, researchers, and implementors.

If you’ve done anything interesting in Linux security over the last year, it’s time to get a proposal ready and send it in!

Dan Walsh: I will be presenting SELinux at Boston Securty Meetup Tonight.

dwalsh@redhat.com — 2011-03-31T11:57:14+00:00

http://www.meetup.com/boston-security-meetup/events/16738054/

Dan Walsh: 10 things you probably did not know about SELinux.. #4

dwalsh@redhat.com — 2011-03-25T12:59:24+00:00

#4 How do I tell whether a domain is confined on an SELinux System?

On SELinux targeted systems, we have confined domains and unconfined domains, and as of RHEL6 and all supported Fedoras we also have permissive domains. SELinux does not block access on processes running in these domains, for the most part.

Unconfined Domains

An unconfined domain is supposed to be a process that has the same rights as it would if SELinux was disabled. There are a few caveats to this though.

Process Transitions

A process transition says when process running as label a_t executes a file labeled b_exec_t it should execute the process as b_t An example of this would be service httpd start. In this case we have unconfined_t running an init script labeled initrc_exec_t and SELinux starts the process as initrc_t.

# sesearch -T -s unconfined_t -t initrc_exec_t
Found 1 semantic te rules:
type_transition unconfined_t initrc_exec_t : process initrc_t;

Then the init script has a rule that says initrc_t executing httpd_exec_t will transition to httpd_t

# sesearch -T -s initrc_t -t httpd_exec_t
Found 1 semantic te rules:
type_transition initrc_t httpd_exec_t : process httpd_t;

This means that even though the process that started another process was unconfined, the new process can be confined. We tend to discourage transitions from the unconfined_t user domain, since this can surprise the user. "I thought I was unconfined, why when I start XYZ does SELinux block it?"

Other then transitioning to initrc_t there are currently 55 executables that transition out of the unconfined_t domain.

# sesearch -T -s unconfined_t -c process -C| grep -v initrc_t| grep -v ^D | wc -l
55

A lot of these domains are also unconfined. unconfined_java_t for example is the same as unconfined_t except it has execstack and execmem privilege always.

Minor Denials

In some cases I have been convinced to add minor confinement to even unconfined domains. The most seen one of these was the executable memory checks. execmem, execmod, execheap and execstack. There are booleans to turn on and off the checks for the unconfined domains.

Listing unconfined domains

You can use seinfo to list the unconfined domains.

# seinfo -aunconfined_domain_type -x | wc -l
54

Disabling unconfined domains

You can easily disable lots of domains unconfined domains to make your machine more locked down. In RHEL6 and Fedora their are two policy modules unconfined and unconfineduser. If you disable unconfined it will lock down most of system space.

# semodule -d unconfined
# seinfo -aunconfined_domain_type -x | wc -l
14

This is how I usually run. In this mode, it will require you to have policy for all apps launched out of init system or xinetd.

You can also disable the unconfined user, by executing the following commands.

# semanage login -m -s staff_u root
# semanage login -m -s staff_u __default__
# semanage user -d unconfined_u
# semanage user -m -R "staff_r system_r sysadm_r" staff_u
# semodule -d unconfineduser

As long as unconfined is not defined in either the semanage user or semanage login database this should work and you pretty much get back to what used to be strict policy.

I tend to leave unconfineduser enabled, but setup all my users as confined, and allow staff_t to transition to unconfined_t through sudo.

Adding unconfined domains to when building policy modules

If you were building your own policy module and you wanted to build an unconfined domain, you would write code like:

type mydomian_t;
domain_type(mydomain_t)

optional_policy(`
          unconfined_domain(mydomain_t)
')

Permissive Domains

The other type of domain that SELinux does not block is the permissive domain.    These are usually domains under construction. SELinux allows these domains to do any thing but reports AVC;s on them when they do something not allowed in policy. When we develop policy for Fedora, we define all new domains as permissive and allow them to run permissive through an entire run of a release. Then in the next release we turn them to enforcing. One difference between F15 and F16 policy is we just removed the permissive flag from all domains in F15.

Listing Permissive Domains

You can see the permissive domains in two ways.

# seinfo --permissive | wc -l
18

Or you can use the semanage command to list them

# semanage permissive -l

Builtin Permissive Types

staff_gkeyringd_t
staff_gkeyringd_t
mock_t
keyboardd_t
matahari_serviced_t
firewalld_t
colord_t
systemd_notify_t
systemd_passwd_agent_t
mozilla_plugin_t
matahari_hostd_t
matahari_netd_t
passenger_t
systemd_tmpfiles_t
foghorn_t
namespace_init_t

Customized Permissive Types

qpidd_t

Adding Permissive Domains

Notice that the semanage command differentiates between customized permissive domains and built-ins. With the semanage command, the administrator can choose to make a domain permissive, by executing

# semanage permissive -a httpd_t
# seinfo --permissive |grep http
   httpd_t

Removing Permissive Domains

You can remove a customized permissive domain by executing:

# semanage permissive -d httpd_t

You can not currently remove permissive domains if they are the built-in into policy.

Adding permissive domains to when building policy modules

If you were building your own policy module and you wanted to build a permissive domain, you would write code like:

type mydomian_t;
domain_type(mydomain_t)

permissive mydomain_t;

Thomas Biege (Security): SAD 2: Security Awareness or melting Realities together

Thomas (noreply@blogger.com) — 2011-03-25T06:36:23+00:00

Most people know that smoking causes cancer, that eating too much and not doing sports increases the probability of a cardiovascular disease, that drinking too much is bad for your psyche and lever and so on.

But does just knowing about it change their behavior? No, it does not!

The reason is that these "invisible" negative effects do not influence their living, the integrity of their reality is intact until it is too late and the disease dramatically decrease the quality of their life.

Only a few people are clever and strong enough to reflect about their bad behaviors and change them. I assume more people change their bad habits as soon as they see what happens to their body. Seeing means measuring the cardiovascular levels, taking x-ray pictures of organs, making chemical analysis of body liquids and tissue and so on.

I see a strong analogy here to software development and security.

Developers and project-managers often do not have security in mind, or do not have the technical background and daily practice to make the resulting product a nightmare for penetration-testers and hackers. (How often do you read this already?)

Let's not stress this doctor vs. patient analogy too far. This blog entry is not about good vs. bad or dumb vs. clever... it's about the experience I made and psychology.

First of all, measurement (of the right things) is the key to success! You do not have to create a bulletproof plan, just some goals, continue measurement, and adapt your plan (Hello agile development/management!).

I hold three talks/workshops in 2010, every talk has the same topic: "secure design and development" and I got the same result: Code quality did not increase! The number of potential security bugs per 1000 "physical" LOC (Hits/KSLOC) stayed the same or even increased.
Based on the responses from my audience I experimented with the content and with the methodology. The first workshop was very long and mostly theoretical with threat models, potential problems in Rails, risk assessment, showing some tools (which gets the most attention, because it potentially helped solving their problems).
The second one was much more practical, I had shown real examples from the in-house software projects, real attacks and presenting some tools. The session was much shorter and caused more attention by the developers and a bit more attention by the technical managers (Still, tools caused the the most attention). And the last one... the last one was a wake-up call, less technical, analogies and examples, cost of security updates (Attention!) and I hit the target.

Result: The first talk was a waste of time, my statistics had shown no decrease in the potential vulnerabilities, the second one also had no affect on quality but the awareness and communication (developers) increased, and the third talk... well the code quality did not increase but awareness and maybe acceptance in the upper food chain increased.

Retrospectively I can say I should have done the talks/workshops in reverse order but when I started is was a "fire-fighter job" and I had no time for a real plan.

Code quality is still a critical issue and therefore I took the next, more aggressive step by sending the (cleaned-up) results of my code scanner to the developers mailing list. And at least one team responded to it and we reduced the number of potential security problems and false positives to a minimum within just two weeks. In the meanwhile all teams responded in some way and I hope code fixing will start soon.

On balance:

If you want to increase awareness, invite the right people and omit technical details, speak the language of the audience, use numbers (costs) and statistics, use analogies instead of theoretical information. Melt realities by creating feelings and concernment! (The last point is not easy to do of course.)
If you want to increase code quality, use tools that directly show the problematic code with a description and help fixing it! Don't create too much confusion and don't steal the developer's time.

BTW, the increase of awareness or the expertise of the developers resulted in adding security features and fixing existing security features...

kostenloser Counter

Dan Walsh: 10 things you probably did not know about SELinux.. #3

dwalsh@redhat.com — 2011-03-24T16:04:06+00:00

SELInux versus nsswitch.conf

Many confined domains call getpwnam, getpwuid, getpwent functions. Traditionally these function calls just read the the /etc/passwd file. In a modern Linux system the glibc has added nsswitch.

man nssswitch.conf
...
NAME
       nsswitch.conf - System Databases and Name Service Switch configuration file

DESCRIPTION
       Various functions in the C Library need to be configured to work correctly in the local environment. Tra‐
       ditionally, this was done by using files (e.g., /etc/passwd), but other nameservices (like the Network
       Information Service (NIS) and the Domain Name Service (DNS)) became popular, and were hacked
       into the C library, usually with a fixed search order.
...

nsswitch functionality allows multiple back-ends for the getpw*. These back-ends can change the access required by a process, and SELinux has to allow for these different back-ends.

If you have setup your system with your passwd data in ldap, SELinux is forced to allow all confined domains that call getpw* to connect to the ldap_port_t ports in order to get passwd data.

# semanage port -l | grep ldap
ldap_port_t                    tcp      389, 636, 3268
ldap_port_t                    udp      389, 636

Also since the confined application needs to resolve the hostname of the ldap server, the confined application needs to be able to connect to dns_port_t.

# semanage port -l | grep dns
dns_port_t                     tcp      53
dns_port_t                     udp      53

Even worse if you are using NIS all of these applications have to be able to connect all ports and bind to all ports.

We have had a boolean allow_ypbind since RHEL5, luckily this is turned off by default and eliminates a lot of access. You only need to turn it on if you are using NIS.

sssd (System Security Services Daemon) to the rescue.

sssd provides a new back end for nsswitch. This backend causes all callers of getpw* functions to used a named socket, /var/lib/sss/nss. The beauty of the sssd backend is the sssd daemon does all of the ldap communications for the confined applications, rather then the confined applications needing to connect directly to the ldap server/port.

In Fedora 15 we added a new boolean authlogin_nsswitch_use_ldap that allows you to turn off this access.

NOTE: You can turn off this boolean even if you are using ldap for passwd entry resolution if you are using sssd.

How many rules does this eliminate?

Using sesearch to look for rules tat allow a domain to connect to the ldap_port_t.

# sesearch -A -t ldap_port_t -p name_connect -C | wc -l
717

If we eliminate the allow_ypbind boolean

# sesearch -A -t ldap_port_t -p name_connect -C | grep -v allow_ypbind | wc -l
386

Now if we further eliminate authlogin_nsswitch_use_ldap

# sesearch -A -t ldap_port_t -p name_connect -C | grep -v allow_ypbind | grep -v authlogin_nsswitch_use_ldap | wc -l
112

Meaning we have eliminate over 600 rules that allow confined domains to connect to the ldap_port_t.

You can turn off both booleans by executing.

# setsebool -P allow_ypbind=0 authlogin_nsswitch_use_ldap=0

I plan on turning both booleans off by default in Fedora 16.

Dan Walsh: 10 things you probably did not know about SELinux.. #2

dwalsh@redhat.com — 2011-03-23T12:13:28+00:00

#2 Outputting your semanage configuration

You set up a machine with a bunch of SELinux customizations. You want to take those customizations and make 5 other machines look the same.

How would I do this?

semanage -o /tmp/selinux.customizations

man semanage
...
       Output local customizations
       semanage [ -S store ] -o [ output_file | - ]

SYNOPSIS
       Output local customizations
       semanage [ -S store ] -o [ output_file | - ]

The semanage -o command will output all semanage customizations into a file that the semanage -i command can read.

# semanage -i /tmp/selinux.customizations
# scp /tmp/selinux.customizations root@otherhost.mycompany.com
# ssh otherhost.mycompany.com root@otherhost.mycompany.com semanage -i selinux.customizations

Here is the output of this command on my laptop.

# semanage output -o -
boolean -D
boolean -1 allow_polyinstantiation
boolean -0 authlogin_nsswitch_use_ldap
boolean -1 httpd_can_sendmail
boolean -1 xguest_connect_network
boolean -1 xguest_mount_media
boolean -1 xguest_use_bluetooth
login -D
login -a -s guest_u -r 's0' __default__
login -a -s unconfined_u -r 's0-s0:c0.c1023' root
login -a -s system_u -r 's0-s0:c0.c1023' system_u
login -a -s xguest_u -r 's0' xguest
user -D
user -a -r s0-s0:c0.c1023 -R 'staff_r system_r webadm_r' webadm_u
user -a -r s0 -R 'xguest_r' xguest_u
port -D
port -a -t http_port_t -p tcp 81
interface -D
interface -a -t netif_t eth*
node -D
node -a -M 0.0.0.0 -p ipv4 -t defaultif_t 0.0.0.0
node -a -M 255.255.255.255 -p ipv4 -t internalif_t 127.0.0.1
fcontext -D
fcontext -a -f 'all files' -t httpd_sys_content_t '/myweb(/.*)?'
fcontext -a -f 'all files' -t public_content_t '/shared(/.*)?'
fcontext -a -f 'all files' -t samba_share_t '/shared/samba(/.*)?'

Notice the -D commands, these are used to delete all local customizations. If you were to install this selinux configuration on your machine, you would have the same configuration as my laptop.

Note:  You would also need to make sure the policy modules were the same on each machine.

Dan Walsh: 10 things you probably did not know about SELinux..

dwalsh@redhat.com — 2011-03-22T18:33:58+00:00

Over the next few days, I am going to blog about things you probably did not know about SELinux

1: Multiple semanage commands:

The semanage command is pretty slow. It can take 10-20 seconds for a semanage command to complete. semanage recompiles a huge amount of policy. In Fedora 15 we have almost 500,000 allow and dontaudit rules. The compiler checking each type, user, role, etc to make sure they are valid.   I have seen people executing multiple semanage commands in post install of rpm spec files as well as people customizing lots of machines by executing setsebool, semodule and semanage commands. Not too many people realize you can run them all within the same transaction.

man semanage
...
       Input local customizations
       semanage [ -S store ] -i [ input_file | - ]
...
    -i, --input
              Take a set of commands from a specified file and load them in a
              single transaction.

The xguest uses this in its post install.

semanage -S targeted -i - << _EOF
boolean -m --on allow_polyinstantiation
boolean -m --on xguest_connect_network
boolean -m --on xguest_mount_media
boolean -m --on xguest_use_bluetooth
_EOF

It sets a bunch of boolean values. You can also manage different semanage commands within the same transaction.

semanage -i - << _EOF
port -a -t http_port_t -p tcp 81
fcontext -a -t httpd_sys_content_t "/myweb(/.*)?"
boolean -m --on httpd_can_sendmail
user -a -R "staff_r system_r webadm_r" -r s0-s0:c0.c1023 webadm_u
login -m -s guest_u -r s0 __default__
_EOF

Thomas Biege (Security): Forgotten Password and Birthday Attacks

Thomas (noreply@blogger.com) — 2011-03-18T08:42:28+00:00

I just stumbled over a piece of code that might be interesting for you as well. A web-app let's click you on a "forgotten password" link and will send a token to the (valid/known) email address you specified. When you return to the web-app and provide the token that was mailed to you, and the token was found by looking it up for ANY user, you are allowed to set a new password. So, theoretically (I didn't test it) this code is vulnerable to a birthday attack (random pair collision), the impact depends on the number of users and the length of the token.

For example, and I hope I get the math correct here, if the token is 8 bit long (8 bit of entropy, equally distributed) an attacker only needs to call the "forgotten password" functionality for 16 (birthday bound, 2^{n/2}) users and try 16 different tokens to have a probability of success close to 50%.

The solution is to look-up the user by email address or another unique identifier and verify if the token for this user matches or not.

Here is an example diagram for a 16 bit token (DNS TRXID) to compare brute force vs. birthday attack.

kostenloser Counter

Thomas Biege (Security): Oops, RSA hacked and SecurID code stolen?

Thomas (noreply@blogger.com) — 2011-03-18T04:44:37+00:00

http://www.rsa.com/node.aspx?id=3872

kostenloser Counter

Andrey Markelov (SELinux): Использование SELinux совместно с iptables

Andrey Markelov (noreply@blogger.com) — 2011-03-17T13:05:47+00:00

Dan Walsh, отвечающий в Red Hat за развитие SELinux опубликовал на Linux.com статью, посвященную использованию SELinux совместно с брандмауэром. Ссылка.

Dan Walsh: I have been fooling around with using SELinux and network labels.

dwalsh@redhat.com — 2011-03-16T17:20:50+00:00

I am constantly playing with new ways of using SELinux to enhance level of security. Lately I have been playing with adding labels related to network connections. I wrote an article that was a little long for a blog, and linux.com was nice enough to publish it for me.

http://www.linux.com/learn/tutorials/421152-using-selinux-and-iptables-together

Hope you enjoy it, or at least understand it.

Dan

Dan Walsh: I appeared this week on FLOSS Weekly, live from my kitchen...

dwalsh@redhat.com — 2011-03-10T14:01:20+00:00

The TWiT Netcast Network with Leo Laporte

156

Thomas Biege (Security): Comdirect bank TAN handling

Thomas (noreply@blogger.com) — 2011-03-10T02:23:03+00:00

Just recognized that the web-app for Comdirect online banking does not ask for another TAN if you choose back and change the bankwire details like the recipient. Execution flow:

Enter bankwire details ---> click next ----> asked to enter TAN n ---> click back ----> change bankwire details ----> click next ---> again asked for TAN n

I would generate a new TAN...

kostenloser Counter

Dan Walsh: Trusted Computing SIG in Fedora

dwalsh@redhat.com — 2011-03-02T18:23:09+00:00

We have just created a SIG (Special Interest Group) in Fedora On Trusted Computing.
 https://fedoraproject.org/wiki/SIGs/Trusted_computing

Check it out and sign up for the Mailing List if you are interested.

Miroslav Grepl: Can you develop your service and keep SELinux in the game?

mgrepl — 2011-02-16T17:39:07+00:00

I still get questions why a service can not be started directly. We (Dan Walsh and me) described this situation many times. So one example could be

# abrtd -d -v

But what does it cause?

* from your point of view

user @ abrtd binary -> abrtd runs

* in SELinux perspective

unconfined_t -> abrtd_exec_t -> unconfined_t

So question is how we can get all your changes to SELinux policy at the time if you develop your service. And you really want or you need to test it this way.

We can not.

But we have a solution for you. Try to use runcon and keep SELinux and us in the game.

It is really easy. Just one or two steps are needed.

1. Make your service running in the proper context.

# runcon -u system_u -r system_r -t initrc_t — runcon -t abrt_t -l s0 — abrtd -d -v

2. Maybe everything will not work correctly and you will not see any AVC messages. Maybe because of dontaudit rules.

So just execute

# semanage permissive -a abrt_t

or you can swith to permissive mode globally if you develop

# setenforce 0

What do you think?

Russell Coker (security): Mplayer, Squeeze, and SE Linux on i386

etbe — 2011-02-16T00:02:59+00:00

I’ve just updated my SE Linux repository for Squeeze to better support running mplayer on the i386 architecture, below is the APT sources.list line:

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

The first issue is a bug in the compilation of the SDL libraries which makes them request an executable stack (bug #613535). Recompiling the libraries on my system caused this bug to go away, so it must be some issue with the compilation process. I have previously summarised the execstack issue, but we haven’t solved this yet [1].

The next issue is the fact that the ffmpeg libraries require execmod access (see my previous post for the details of the execmod issue [2]. The execmod issue with ffmpeg is pretty much the same as it was when I first wrote about the issue in 2008 [3]

Finally the allow_execmem boolean needs to be set on i386 with the command “setsebool -P allow_execmem 1” to allow libGL the access it needs. This is an issue I haven’t been able to solve, I don’t know why libGL needs write and execute access to memory, I posted to the SE Linux list about this some time ago but didn’t get any good answers [4]. Any suggestions would be appreciated.

Dan Walsh: Strange SELinux AVC's

dwalsh@redhat.com — 2011-02-14T15:59:57+00:00

A bug was just closed where the google chrome plugin sandbox was trying to read a link file within the homedir.

SELinux is preventing /opt/google/chrome/chrome from read access on the lnk_file /home/physics-tools/clhep/clhep

Here is the AVC.

type=AVC msg=audit(1297435306.238:20321): avc: denied { read } for pid=22631 comm="chrome" name="clhep" dev=sda5 ino=8195388 scontext=unconfined_u:unconfined_r:chrome_sandbox_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:user_home_t:s0 tclass=lnk_file

type=SYSCALL msg=audit(1297435306.238:20321): arch=c000003e syscall=2 success=no exit=-2 a0=7fffb3534570 a1=0 a2=0 a3=2f7065686c632f70 items=0 ppid=0
pid=22631 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=7 comm="chrome"
exe="/opt/google/chrome/chrome" subj=unconfined_u:unconfined_r:chrome_sandbox_t:s0-s0:c0.c1023 key=(null)

clhep is included in a high energy physics library

On the surface this makes no sense at all. You would figure there is not way the chrome sandbox would be reading this random link in the users home directory to the high energy physics library.

But digging further we found that the .bashrc was executing /home/physics-tools/env/clhep_scr. This script was modifying the LD_LIBRARY_PATH to include many new paths including /home/physics-tools/clhep/clhep.

When you start any application including chome, all paths within the LD_LIBRARY_PATH will be searched.

This explains why the AVC was generated.

Miroslav Grepl: PLAYING WITH SELINUX … PART #3

mgrepl — 2011-02-08T15:23:36+00:00

The third part of our playing with SELinux is about vncserver. Why vncserver? I want to show you creating new policies is not always necessary. Also I remember we had really hard time to make vncserver working .

First, we need to setup vncserver.

# yum install tigervnc-server
# chcon -t bin_t `which /usr/bin/vncserver`

Make your /etc/sysconfig/vncserver looking like

# cat /etc/sysconfig/vncservers
VNCSERVERS=”1:myusername”
VNCSERVERARGS[2]=”-geometry 800×600 -nolisten tcp -localhost”

Add vnc password and start vncserver

# vncpasswd $myusername
# service vncserver start
# ps -eZ | grep vnc

system_u:system_r:initrc_t:s0 5558 ? 00:00:00 Xvnc
system_u:system_r:initrc_t:s0 5568 ? 00:00:00 vncconfig

How you know from the first part of blog

initrc_t -> bin_t -> initrc_t

Now try to use the vncserver

# vncviewer localhost:1

You might want to say: "It looks good, it works". But really? Try to run terminal in the vncviewer

# id -Z
system_u:system_r:initrc_t:s0

Bingo. You ended up with the wrong context. What does it mean? You could screw up your machine with wrong labels. For example:

# touch /tmp/test
# ls -lZ /tmp/test
-rw-rw-r--. mgrepl mgrepl system_u:object_r:initrc_tmp_t:s0 /tmp/test

But this is a wrong context for user's files in the /tmp directory. Should be:

# ls -lZ /tmp/test1
-rw-rw-r--. mgrepl mgrepl staff_u:object_r:user_tmp_t:s0 /tmp/test1

So how to fix it? By a new policy? It does not make sense in this case. The vncserver would end up as unconfined domain and screw up our machines. We needed to find out a different solution.

... SELinux is all about labels.

Now run.

# restorecon -v `which vncserver`
restorecon reset /usr/bin/vncserver context system_u:object_r:bin_t:s0->system_u:object_r:unconfined_exec_t:s0

And yes, you are seeing our solution. We added the "unconfined_exec_t" label for the vncserver binary.

# service vncserver restart
# ps -eZ | grep vnc
system_u:unconfined_r:unconfined_t:s0 6237 ? 00:00:00 Xvnc
system_u:unconfined_r:unconfined_t:s0 6245 ? 00:00:00 vncconfig
# vncviewer localhost:1
# id -Z
system_u:unconfined_r:unconfined_t:s0

And we got the right context for unconfined SELinux user.

Miroslav Grepl: Playing with SELinux … part #2

mgrepl — 2011-02-08T15:20:35+00:00

But we want to see whether it really works and how we can use Permissive Domains.

We will setup the httpd service to listen on 631/tcp port which is used by CUPS. The portreserve service should prevent to apache from using this port. This is a way how portreserve works.

# man portreserve
portreserve – reserve ports to prevent portmap mapping them

Make sure portreserve is running.

# service portreserve status 2>&1 >/dev/null; echo $?;
0

Setup apache, portreserve and try to start apache.

# if [ -e /etc/portreserve/cups ]; then echo “The file exists”; else `echo “ipp” > /etc/portreserve/cups`;service portreserve restart;fi;
# sed -i s/^Listen\ [0-9][0-9]*/Listen\ 631/ /etc/httpd/conf/httpd.conf
# date_time=`date +%T`
# service httpd start 2>&1 >/dev/null; echo $?;
1

What is a reason apache is not running? Either because portreserve works or because of SELinux? We should analyze it.

# ausearch -m avc -ts $date_time | audit2allow
#
#
# #============= httpd_t ==============
# #!!!! This avc can be allowed using the boolean ‘allow_ypbind’
#
# allow httpd_t ipp_port_t:tcp_socket name_bind;

In deed, apache is not allowed to use 631/tcp port which is expected. But we want to allow it for our test. How can we do it?

Turn off SELinux, set a machine to permissive mode?

Answer is NO!!!

You can allow it using a local policy.

# grep avc /var/log/audit/audit.log | audit2alow -M mypol
# semodule -i mypol.pp

or use “Permissive Domains”.

# semanage permissive -a httpd_t

This is a way how we do it. How we debug an existing policy, how people can really help us with testing of policies. I like this feature. Make our and your life easier and safer!

# semanage permissive -l | grep -w httpd_t
httpd_t

So now we can restart apache and finally see if portreserve works.

# service httpd start 2>&1 >/dev/null; echo $?;
1

It works! Are you sceptic?

# service portreserve stop
# service httpd start
# echo $?
0

We are done. I believe you like SELinux more now.

Also you should replace your local portreserve policy by the defaul policy.

# semodule -r portreserve.pp -i /usr/share/selinux/targeted/portreserve.pp.bz2
# for files in `rpm -ql portreserve | grep -E “(etc|bin|log|lib|run)”`;do restorecon -R -v $files;done;
# semanage permissive -d httpd

Dominick Grift: selinux q&a

Dominick "domg472" Grift (noreply@blogger.com) — 2011-02-08T14:22:41+00:00

23:15 someone> What's the difference between httpd_sys_rw_content_t and
httpd_sys_content_rw_t?
23:19 dgrift> none
23:19 dgrift> their aliased
23:19 dgrift> theyre

Miroslav Grepl: Playing with SELinux … part #1

mgrepl — 2011-02-07T22:11:00+00:00

This Friday I am going to have a speech/workshop at DeveloperConference2011. Together with Eduard Benes we will guide you through a process of using permissive domains for developing a SELinux policy and using it for your advantage and tell you something about sVirt.

I decided to write a blog related to this workshop. You can go through this blog, try it and prepare some questions. I would also recommend you to look at writing SELinux Policy blog in which Dan Walsh explains some basics of SELinux.

But now back to my blog . I was thinking during my Friday’s travelling which a good example I would show you. An example which really works. I chose the combination of apache, CUPS and portreserve services (btw. portreserve was my first policy written in Red Hat).

Ready to play with SELinux?

1. First, we need to setup our environment. Stop all intended services and remove the default portreserve policy. We also need to run the restorecon command to restoring contexts.

# for s in portreserve cups httpd; do service $s status 2>&1 >/dev/null; if [ $? -eq 0 ]; then service $s stop; fi; done;
# semodule -r portreserve
# for files in `rpm -ql portreserve | grep -E “(etc|bin|log|lib|run)”`; do restorecon -R -v $files; done;
# service portreserve start

2. Now you can check the context of portreserve service.

# ps -eZ | grep initrc
system_u:system_r:initrc_t:s0 3374 ? 00:00:00 portreserve

What happened while we were starting the service? Init script executing the portreserve binary labeled bin_t did not transition and stayed in the same context as the parent process.

initrc_t -> bin_t -> initrc_t

Really important to understand.

!! SELinux is all about labels!!

If we had tried to setup the cupsd_exec_t context for the portreserve binary, the service would have run in the cupsd_t domain.

initrc_t -> cupsd_exec_t -> cupsd_t

since we define this transition. So let’s create a new policy which will say

initrc_t -> portrserve_exec_t -> portreserve_t

3. Use the sepolgen command.

# sepolgen –help

Since the portreserve is a standard init daemon.

# service portreserve stop
# sepolgen -t 0 `which portreserve`

Created the following files in:
./
portreserve.te # Type Enforcement file
portreserve.if # Interface file
portreserve.fc # File Contexts file
portreserve.sh # Setup Script

4. Install the portreserve policy.

# sh portreserve.sh

Do some checks.

# semodule -l | grep portreserve
portreserve 1.0.0

# ls -Z `which portreserve`
-rwxr-xr-x. root root system_u:object_r:portreserve_exec_t:s0 /sbin/portreserve

It was really easy . We have now the basic portreserve policy. Why not try it?

# service portreserve start
# ps -eZ | grep portre
system_u:system_r:portreserve_t:s0 3498 ? 00:00:00 portreserve

Maybe you would like to ask me: “Is this policy really working? We have Enforcing mode and the daemon is running”. Well I have two answers for you .

a. You can check how the initial policy is good using

# ausearch -m avc -ts recent

Probably you will see some AVC messages which are really important for the next steps.

b. The magic there is the portreserve is running as a permissive domain.

This means while SELinux access ckecks are performed for these domains, but they are not enforced. The kernel allows the access and reports it as an AVC denial. We can push out a new policy as permissive domain and simply collect AVC messages. Users don’t have to switch to permissive mode globally and they can stay in the enforcing mode.

Now we can easily to complete/finish our policy using ausearch, audit2allow tools (which are my favourite)

# service portreserve restart
# ausearch -m avc -ts today | grep portreserve | audit2allow -R >> portreserve.te

Compile and load it:

# make -f /usr/share/selinux/devel/Makefile
# semodule -i portreserve.pp

Now we should test if the policy works without the “permissive domain” declaration.

# date_time=`date +%T`
# sed -i s/^permissive/#permissive/ portreserve.te
# make -f /usr/share/selinux/devel/Makefile
# semodule -i portreserve.pp
# service portreserve restart 2>&1 >/dev/null; echo $?;
0

Looks good. Maybe one additional check would be fine.

# ausearch -m avc -ts $date_time
no matches

CONGRATULATIONS.

Dominick Grift: frequently asked questions: selinux booleans in detail.

Dominick "domg472" Grift (noreply@blogger.com) — 2011-02-06T14:53:32+00:00

Q: "btw, anyone know if each of the selinux booleans are documented in detail somewhere?"

A: two levels of detail here:

1. semanage boolean -l | grep httpd_enable_homedirs
A written description (usually not very detailed) for the "httpd_enable_homedirs" boolean.

2. sesearch --allow -SC -T | grep httpd_enable_homedirs
All the "allow" type statement rules and type transition rules related to the "httpd_enable_homedirs" boolean. Very detailed but hard to interpret.

Dominick Grift: common issues -- part 1

Dominick "domg472" Grift (noreply@blogger.com) — 2011-02-06T13:49:16+00:00

22:13 _Tassadar> hi
22:14 _Tassadar> http://fedoraproject.org/wiki/SELinux/samba - i'm reading this document, on how to
configure selinux to allow samba to share a certain directory
22:14 _Tassadar> now i'd like to share /data/files so i issued chcon -t samba_share_t /data/files
22:14 _Tassadar> it worked, according to ls -Z
22:14 _Tassadar> but access is still denied
22:15 _Tassadar> should i recursively set that label to every file in the share as well?
22:16 SwifT> _Tassadar: (without reading the file) check your AVC denials on what is actually denied, but I
would say "yes, you'll probably want to recursively set the type"
22:17 _Tassadar> SwifT: what is the best way to check my AVC denials?
22:17 _Tassadar> it's a server, i don't have any gui tools
22:20 dgrift> _Tassadar: try Fedora manage confined services
22:20 _Tassadar> hm no new entries appear in /var/log/audit/audit.log
22:20 SwifT> _Tassadar: depends on your system log configuration; try tail -f /var/log/messages or
/var/log/audit.log
22:20 _Tassadar> some stuff from cron appears every five mins, but nothing from smb
22:20 dgrift> _Tassadar this is a common issue
22:20 dgrift> its this:
22:21 dgrift> youve created a new mountpoint called /data
22:21 dgrift> selinux doesnt know that location
22:21 dgrift> and so it labels it with a type: default_t
22:21 dgrift> this is a type for locations unknown to selinux
22:21 dgrift> and selinux silently denies access to type default_t
22:22 dgrift> because it should not happen
22:22 dgrift> all locations should be labelled properly
22:22 _Tassadar> ah
22:22 _Tassadar> i see
22:22 dgrift> so how to fix it?:
22:22 _Tassadar> with restorecon probably
22:22 dgrift> well you should start by labelling /data
22:22 dgrift> what type to label it, that depends on your requirements for /data
22:23 _Tassadar> well it's all user data
22:23 dgrift> var_t should probably do
22:23 dgrift> i see
22:23 _Tassadar> no binaries, no devices
22:23 _Tassadar> lots of mp3's :)
22:23 dgrift> whats in /data?
22:23 dgrift> only dirs?
22:23 _Tassadar> yes
22:23 _Tassadar> /data/home/user1 /data/home/user2
22:24 _Tassadar> /data/home/public_area
22:24 _Tassadar> /data/public_area i mean
22:24 dgrift> whats your distro?
22:24 _Tassadar> Fedora 14
22:24 dgrift> ok heres my suggestion
22:24 dgrift> what is /data/home/user1 labelled?
22:24 _Tassadar> nothing yet
22:25 dgrift> but thats a user home dir?
22:25 _Tassadar> drwx------. joe users unconfined_u:object_r:samba_share_t:s0 joe
22:25 _Tassadar> well
22:25 _Tassadar> i labelled it samba_share_t
22:25 dgrift> ok
22:25 _Tassadar> that's what the docs told me to do :)
22:26 dgrift> what do you want?
22:26 _Tassadar> well it doesn't work yet
22:26 dgrift> what do you want with those dirs?
22:26 _Tassadar> i would like the user to be able to mount his directory from a windows workstation
22:26 dgrift> what is your requirement
22:26 dgrift> i see
22:26 _Tassadar> users are allowed read/write access to their own directories
22:26 dgrift> and not use it locally?
22:26 _Tassadar> and also in the public_area
22:26 _Tassadar> no
22:26 dgrift> ok
22:26 _Tassadar> no shell access
22:27 _Tassadar> no local processes are to be started from /data
22:27 dgrift> so label /data root_t and the other dirs in there samba_share_t
22:27 _Tassadar> recursively?
22:27 dgrift> semanage -a -t root_t -f -d /data
22:28 dgrift> semanage -a -t samba_share_t "/data/home(/.*)?"
22:28 dgrift> restorecon -R -v /data
22:28 dgrift> that will label the data dir root_t
22:28 _Tassadar> nice
22:28 _Tassadar> what does root_t mean?
22:28 dgrift> and /data/home and all below it samba_share_t
22:29 dgrift> it means it the type for filesystem roots
22:29 dgrift> basically its accessable by all
22:29 _Tassadar> oh okay, that makes sense in this case
22:29 dgrift> see if it work
22:29 _Tassadar> what would the -a option do?
22:29 _Tassadar> my system doesn't know -a
22:29 _Tassadar> oh
22:29 _Tassadar> it does
22:29 dgrift> oops
22:30 _Tassadar> something else is wrong
22:30 dgrift> non i made a booboo
22:30 _Tassadar> okay
22:30 dgrift> semanage fcontext -a -t root_t -f -d /data
22:30 dgrift> semanage fcontext -a -t samba_share_t "/data/home(/.*)?"
22:30 dgrift> restorecon -R -v /data
22:31 _Tassadar> lol okay that could take a while
22:31 _Tassadar> i'll run it without -v
22:31 dgrift> hopefully it works for you
22:31 dgrift> yes ok
22:31 _Tassadar> it's a 11TB mount ;)
22:31 dgrift> ouch....
22:31 dgrift> all data on it?
22:31 _Tassadar> yeah, no worries though, i'm not in a hurry
22:32 _Tassadar> it's 60% used ;)
22:32 dgrift> geez
22:32 dgrift> i hope we get this right first time...
22:32 dgrift> might want to test first
22:32 dgrift> with a small dir
22:32 _Tassadar> heh
22:32 _Tassadar> i suppose so
22:32 _Tassadar> ....
22:33 dgrift> chcon -R -t samba_share_t /data/home/smalluserdir
22:33 dgrift> chcon -t root_t /data
22:34 _Tassadar> okay i'll try that
22:34 dgrift> errr
22:34 dgrift> its like this:
22:34 dgrift> chcon -t root_t /data
22:34 dgrift> chcon -t /data/home
22:34 dgrift> err
22:34 _Tassadar> ?
22:34 _Tassadar> lol
22:34 dgrift> chcon -t samba_share_t /data/home
22:34 dgrift> chcon -R -t samba_share_t /data/home/smalluserdir
22:35 dgrift> so three lines
22:35 _Tassadar> yeah i understand, but restorecon is already running so /data and /data/home are already done
;)
22:35 dgrift> because theres 3 dirs
22:35 _Tassadar> i just tried with a small userdir and it works great !
22:35 dgrift> ok
22:35 _Tassadar> but, how do i keep everything neat
22:35 _Tassadar> does restorecond do that?
22:35 _Tassadar> i mean every time someone adds a file
22:36 _Tassadar> it should get the right label immediately
22:36 dgrift> it inherites the type of the parent dir
22:36 dgrift> so should be fine
22:36 _Tassadar> ah i see
22:36 _Tassadar> so what does restorecond do then?
22:36 dgrift> try it
22:36 dgrift> well it watches directories for mislabelled files
22:36 dgrift> but in your case its not applicable
22:37 dgrift> because theres only one type
22:37 _Tassadar> -rw-rw----. joe users unconfined_u:object_r:samba_share_t:s0 zzzzz.txt
22:37 _Tassadar> yeah that works
22:37 dgrift> samba_share_t
22:37 _Tassadar> ah mislabelled, so not unlabelled
22:37 _Tassadar> i understand
22:37 _Tassadar> real 5m32.340s
22:37 dgrift> well and unlabelled aswell
22:37 _Tassadar> done :)
22:37 dgrift> fast system
22:37 _Tassadar> yeah :)
22:38 dgrift> i should blog about this issue
22:38 dgrift> its very common
22:38 _Tassadar> definately
22:39 dgrift> and people wonder why its not logging denials
22:39 _Tassadar> yeah and the fact that audit.log doesn't show anything makes it hard to track for newbies like
me
22:39 _Tassadar> exactly :)
22:39 dgrift> can i use this chat log?
22:39 dgrift> to publish?
22:39 _Tassadar> errrr :)
22:39 _Tassadar> i suppose

Dan Walsh: selinux-polgengui

dwalsh@redhat.com — 2011-02-04T19:28:53+00:00

I am working on preparing a course for Writing Policy with SELinux for the Red Hat Summit. I gave the first version of the talk at FudCon 2011 in Tempe. I noticed the selinux-polgengui was getting a little old looking. This is the tool I advise people to use in order to start writing policy. It generates a group of policy files for you based on you answering a series of questions. Once you have your initial policy you can go use audit2allow or slide to continue writing the policy.

Any ways here is what the latest tool looks like in Fedora 15. I will demonstrate writing a policy for sandbox. I thought about writing policy to run thunderbird within a sandbox.

# selinux-polgengui

Select Sandbox, Hit Forward

You need to name the policy, In this case I called it sandbox_mail. Click Forward

Since the sandbox_mail app will not be binding to any network ports, I click Forward again.

I add ports 25, 143, 993 as ports the sandbox will be allowed to connect to. Forward.

I decide I want to create a boolean called sandbox_mail_connect_all, with the goal of allowing the domain to connect to the entire network.

Click forward.

I tell the tool to create the policy files in the /tmp directory and click Apply.

The selinux-polgengui tool creates the the policy files and a script to install them.

Now you execute the sandbox_mail.sh install script.

# sh sandbox_mail.sh
Building and Loading Policy
+ make -f /usr/share/selinux/devel/Makefile
Compiling targeted sandbox_mail module
/usr/bin/checkmodule: loading policy configuration from tmp/sandbox_mail.tmp
/usr/bin/checkmodule: policy configuration loaded
/usr/bin/checkmodule: writing binary representation (version 10) to tmp/sandbox_mail.mod
Creating targeted sandbox_mail.pp policy package
rm tmp/sandbox_mail.mod tmp/sandbox_mail.mod.fc
+ /usr/sbin/semodule -i sandbox_mail.pp

Now you can test out your policy in a different terminal

> sandbox -X -t sandbox_mail_t thunderbird

Thunderbird should run fine, since selinux-polgengui defined the SELinux types as permissive. You might want to use a permanent Home and Tmp since you will need to configure the thunderbird setup.

After running some test with thunderbird, you can use the audit2allow tool to generate more rules for your sandbox_mail sandbox.

# grep sandbox_mail_t /var/log/audit/audit.log | audit2allow -R >> sandbox_mail.te

Examine the generated rules to see if they make sense.

# shell sandbox_mail.sh

Try the sandbox again and see if you eliminated all of the AVC's. When you are satisfied the policy works the way you want, you can remove the permissive lines from the te file.

Please send any Ideas on improving the GUI to me.

Miroslav Grepl: Does a new mod_rails AKA Passenger work with the current Fedora SELinux policy?

mgrepl — 2011-02-03T21:55:34+00:00

Sometime ago I got the first email about new version Passenger which was not working with our passenger policy.

How some of you know there is a blog which gives you a lot of useful information how to do Passenger working on Fedora.

I mean

http://mifo.sk/posts/passenger-selinux-for-fedora/

The blog will be updated to provide correct instructions to make Passenger v2 and newer version working. Actually just one step will be changed. It is the fifth point looking like:

5. Use restorecon to fix labels:
# restorecon -R -v /usr/lib/ruby/gems/1.8/gems/passenger*
# restorecon -R -v /var/run/passenger* /var/lib/passenger*

The restorecon command will be needed until Passenger is packaged by Fedora (AFAIK it will be soon).

I believe these are great news for people.

Also I have re-written the Fedora passenger policy (changes are based on Dominick’s policy). This policy is much more safer and passenger guys are testing it this time.

But if you are interested, send me an email and I can provide you the policy for testing. I will be happy .

Dan Walsh: Dan Walsh Tweeting? Follow rhatdan

dwalsh@redhat.com — 2011-02-03T17:50:07+00:00

I have finally broken down and did my first tweet, not sure how often I will do it or if it will always be about SELinux/Open Source. Then again I never thought I would blog much.

But if you want to follow me, sign up for rhatdan.

Dan Walsh: Presenting at Fudcon.

dwalsh@redhat.com — 2011-01-30T19:23:42+00:00

These are the links to the presentations I have given at Fudcon.

Writing SELinux Policy
http://people.fedoraproject.org/~dwalsh/SELinux/Presentations/PolicyGeneration.odp

Introducingthe SELinux Sandbox
http://people.fedoraproject.org/~dwalsh/SELinux/Presentations/sandbox.odp

FudCon talks:
Interesting talks on autoQA. The basic idea of this tool was to look at Updates and make sure they don't break the distribution.
For example they are doing a dependency check on an update package, and if it fails, the package will not be allowed to be pushed.
One suggestion I had for the tool was to make sure the updated package did not cause the Minimal Install to increase size. Similarly it could make sure the desktop livecd would still fit on a cdrom or whatever the maximum size is.

Only saw the tail end of the Matahari talk, but looks like an interesting product, that we might be able to take advantage of. We need to write SELinux policy for it, and some how figure we could use sectool/openscap with it.

Attended the Spins Talk, which I am still interested in integrating the ability to build the kiosk OS.

Thomas Biege (Security): Mail: recent security breaches of open-source sites

Thomas (noreply@blogger.com) — 2011-01-28T06:10:17+00:00

This mail was sent out to some opensuse mailing lists to increase awareness.

Dear community members and contributors,

in the last few month we saw security breaches at gnu.org[1], at
sourceforge.net[2] and at fedora[3].

Even if it is believed that the integrity of the hosted projects
was not affected I want to take the opportunity to remind you to
always verify the cryptographic checksums of downloaded archive
files, review patches and keep a healthy relationship/communication
to the upstream authors.

It is good practise to change your password from time to time and make
it hard to guess[4][5]. Take extra care using public wifi hotspots,
crowded places[6], like trains, and other peoples computer etc.

Cheers,
Thomas

[1] http://blog.sucuri.net/2010/11/savannah-gnu-org-hacked-and-currently-offline.html
[2] http://sourceforge.net/apps/wordpress/sourceforge/2011/01/27/service-downtime/
[3] http://lists.fedoraproject.org/pipermail/announce/2011-January/002911.html
[4] http://en.wikipedia.org/wiki/Password_strength
[5] http://sourceforge.net/projects/pwgen/
[6] http://en.wikipedia.org/wiki/Shoulder_surfing_%28computer_security%29

kostenloser Counter

Dan Walsh: Red Hat Virtual Experience January 26, 2011 1PM EST

dwalsh@redhat.com — 2011-01-25T15:24:07+00:00

http://www.redhat.com/virtual/

Red Hat Enterprise Linux 6: Security

Daniel Walsh — Principal Software Engineer, Red Hat

In this session, Daniel Walsh will show attendees new SELinux features and explain how to use them in Red Hat Enterprise Linux 6. He will cover several SELinux topics, including:

Confining users
Securing your virtual environment
Securing the desktop
Controlling grid jobs
Sandboxing: putting the power into the hands of the administrator
Building and shipping your own SELinux policy

Dan Walsh: Attending FudCon in Tempe Arizona this weekend.

dwalsh@redhat.com — 2011-01-25T15:11:32+00:00

If you are going to be there stop by and say hi.

Will probably do some talks on SELinux, including talking about Writing Policy and Using Iptables and SELinux together to confine applications.

http://fedoraproject.org/wiki/FUDCon:Tempe_2011

Dominick Grift: Yet another step by step introduction to policy development.

Dominick "domg472" Grift (noreply@blogger.com) — 2011-01-24T06:52:17+00:00

Due to several requests for guides to writing SELinux policy i have decided to create another screen cast detailing how to create a policy for a user application, and some of the things that may help one get familiar with policy writing.

As per usual by now, it is just a amateur production for amateurs. These recordings are pretty boring and long. I do advise that you view the whole thing in the proper order. Because things may not be explained well all the time, but most of it should become more clear in the course of the series.

Sometimes i make mistakes that i later notice. By the end of the series everything is pretty much sorted out (except atleast one pretty minor issue that i consider as an exercise to the watcher to troubleshoot and solve).

Also note that i encountered a conflict with restorecond -u (run in a gnome-session) with regard to labelling a file in the user home directory. I worked around that issue, but it will work fine when one logs out and back in, when it occurs.

part 1. Setting up an optimal environment for policy writing and in the mean time i explain my view on policy writing and every aspect of it.

http://www.youtube.com/watch?v=s4EyoW_7riQ

part 2. Do it yourself: create a simple script and write raw policy for it. Introduction to type transition, allow, dontaudit and other type statements. A start at translating raw policy that SELinux understands into policy that is maintainable and readable by humans and that is scalable in a modular environment.

http://www.youtube.com/watch?v=G5gUt1-ttGg

part 3. Proceed with translation of raw policy to m4 macro language powered policy. Merge our loadable policy module into upstream tresys reference policy.

http://www.youtube.com/watch?v=nbFnchVAgYs

part 4. troubleshoot remaining issues and fix them.

http://www.youtube.com/watch?v=rUGBgzTr92A

If you have specific question with regard to the series above feel free to ask for clarification.

Russell Coker (security): Continuously Usable Testing of SE Linux

etbe — 2011-01-22T08:48:31+00:00

Joey has proposed a new concept of “Continuously Usable Testing” for Debian [1], basically testing should be usable at all times and packages that aren’t usable should be dropped. But to properly achieve this goal we need continual testing of usability.

The Plan For SE Linux

To do this for SE Linux I’m setting up a Xen server which will have a number of different DomUs for testing a variety of server applications. The system has 1.5G of RAM and 160G of mirrored storage. An image of a typical server will take about 4G of disk space, so we could have something like 40 images online and ready for testing. I have already setup Squid on another system on the same LAN to cache Debian packages, so running “apt-get dist-upgrade” on a number of DomUs won’t take that long. With 256M for a typical server image I could have 5 images running at the same time. If the hardware isn’t enough then I can expand it, I hope to get some donations of DDR-266 or DDR-333 RAM (or maybe DDR-400) to upgrade the system to 4G of RAM, I can add more hard drives, and I could even install more servers.

I want to have testing be very usable for SE Linux throughout the development cycle so that I don’t have to rush things before release.

At this stage I’m not sure whether to track Unstable or Testing for this. I guess it might be best to track Testing most of the time and only track Unstable for daemons that are changing rapidly. It might get boring testing every version that comes through Unstable, but if people want to do this then I won’t stop them.

Setting up the Tests

What I need are interested people who want to install server configurations for testing. If you have some favorite combination of daemons that you want tested for SE Linux support (even if it’s daemons that have no current policy) then I can give you root access to a DomU to develop test cases. Ideally there would be automated tests used for most things for example testing a mail server by using swaks to deliver mail and a POP or IMAP client script to retrieve it. But some things can’t be tested properly without human intervention.

For the automated tests I want to script the creation of DomUs, upgrading the packages in the DomU, testing it, and then shutting down the DomU if it all works. If at any time the tests fail (or the upgrade fails) then it would wait for human intervention. That would be me fixing SE Linux problems and other people fixing the application problems. I think that discovering SE Linux issues will only be a part of this project.

For the manual tests I will grant access to create and destroy the DomUs in question to people who can run the tests.

I’m thinking of having a couple of DomUs running permanently for things which are test candidates but also useful for the project, such as a MediaWiki instance. It really depends on the interest of people who might use such things.

Also I’m thinking of setting up some Ubuntu DomUs too, I probably should join Ubuntu and get involved with SE Linux there.

Sharing the Images

I have a web server in Germany with almost unlimited bandwidth and storage. For every image that is created I want to upload a version to the server in Germany to allow anyone in the world to test it. There are lots of possible ways of using this for software development. For example if you had a patched version of Apache that you wanted to test then you could download every image that had Apache installed and test that they all work. That would be easier than configuring Apache in different ways and also possibly provide better coverage.

Also if someone can’t figure out how to configure a daemon correctly then downloading a Xen image of a working configuration could be helpful (if a little bandwidth intensive). Note that deploying such an image in production would be a really bad idea, among other things there are lots of places where passwords are stored and you wouldn’t want to risk missing one.

I also plan to share the scripts used in running the Dom0 and anything else that seems useful along the way.

What We Need

The main thing we need is volunteers to configure virtual machines with their favorite daemons. Note that I don’t plan to have only one daemon per DomU, if we can get multiple daemons running that don’t conflict (EG file server and mail server) or multiple daemons that can interact (EG database server and a mail server or anything else that can be a database client) running on the same system then that’s a good thing. So there will be some degree of interaction with other people.

I’m happy to accept contributions from people who aren’t interested in SE Linux. But SE Linux will run on all DomUs.

Finally I also need more RAM for a HP D530S, DU875PA (that’s a Celeron 2.4GHz). I’ll accept donations of complete systems too once my HP system gets full, preferably relatively low power systems as they will be housed in a location that’s not as well ventilated as I would like (cost and availability of IP addresses were the main criteria). A laptop with a broken screen would be great!

The system won’t go live until Monday, but I think that probably people won’t be ready to do much work with less than two days notice anyway.

[1] http://kitenet.net/~joey/code/debian/cut/

Dan Walsh: execstack on the rampage II

dwalsh@redhat.com — 2011-01-17T18:54:27+00:00

In one of the allow_execstack bug reports someone asked me, shouldn't the tools do a better job of discovering the cause of the execstack? I needed a better way of figuring out what library was causing the execstack AVC,

Since all I have in the AVC is the source path, I figured could use ldd to list the libraries used by it. Then I could examine these libraries using execstack -q and see if any had the flag execstack flag turned on.

Nalin Dahyabhai suggested that I should also search /proc/PID/maps for shared libraries that might have been dlopened.

I wrote the python script findexecstack which takes an executable path and optional pid as parameters. It then reports any execstack libraries that if finds used by the executable or PID.

I am now adding this code to the allow_execstack setroubleshoot plugin which should give us a better troubleshooting and say something like:

If you believe the APPLICATION does not need execstack and you have a libary /usr/lib/libxvid.s0 requiring it you can execute

execstack -c /usr/lib/libxvid.s0

And try the app again.

If you get the execstack violation, please try out the script until I get the new plugin pushed.

Thomas Biege (Security): Tool: OWASP test-suite

Thomas (noreply@blogger.com) — 2011-01-12T06:06:26+00:00

A happy new year!

I quickly hacked a test-suite based on the OWASP testing-guide. You can find the code here: http://gitorious.org/sectestsuite/websec

Take care, this time it is untested, incomplete and unfancy.

prompt> src/websec.pl myconfig.ini output=short
=====> OWASP_CM_001::sslv2: CWE-XYZ (): code = 0 (msg = 'PASS')
=====> OWASP_CM_001::weak_ciphers: CWE-327 (Use of a Broken or Risky Cryptographic Algorithm): code = 0 (msg = 'PASS')
=====> OWASP_CM_008::http_dangerous_methods: CWE-749 (Exposed Dangerous Method or Function): code = 0 (msg = 'PASS')
=====> OWASP_CM_008::http_arbitrary_methods: CWE-749:CWE-650 (Exposed Dangerous Method or Function:Trusting HTTP Permission Methods on the Server Side): code = 1 (msg = 'FAIL:HTTP arbitrary/dangerous methods allowed (UNLOCK)')
=====> OWASP_CM_008::http_bypass_head: CWE-650 (Trusting HTTP Permission Methods on the Server Side): code = 0 (msg = 'PASS')
=====> OWASP_AT_002::user_enumerate: CWE-204 (Response Discrepancy Information Exposure): code = 0 (msg = 'PASS')
=====> OWASP_AT_002::uri_probing: CWE-204 (Response Discrepancy Information Exposure): code = 1 (msg = 'FAIL:URI probing emits different HTTP status code (200 vs 404)')
=====> OWASP_AT_007::user_really_logged_out: CWE-672 (Operation on a Resource after Expiration or Release): code = 1 (msg = 'FAIL: Still able to access private page even after logging out.')
OWASP_AT_007::session_timeout_used: wait for 120 + 10 seconds
=====> OWASP_AT_007::session_timeout_used: CWE-613 (Insufficient Session Expiration): code = 0 (msg = 'FAIL: Private page was still accessible after timeout (120 + 10 secs).')
=====> OWASP_AZ_001::path_traversal: CWE-22 (Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')): code = 0 (msg = 'PASS')
=====> OWASP_SM_002::cookie_security: CWE-614 (Sensitive Cookie in HTTPS Session Without 'Secure' Attribute): code = 1 (msg = 'FAIL:Path attribute points to '/'')
=====> OWASP_SM_003::session_fixation_public: CWE-384 (Session Fixation): code = -2 (msg = 'INFO: Unable to get Cookie from public page')
=====> OWASP_SM_003::session_fixation_private: CWE-384 (Session Fixation): code = 1 (msg = 'FAIL:Vulnerable to Session Fixation Attack by authenticated users')
=====> OWASP_SM_004::cookie_not_fresh: CWE-323 (Reusing a Nonce, Key Pair in Encryption): code = 1 (msg = 'FAIL: Vulnerable of re-using session cookies')
=====> OWASP_SM_004::cookie_secure_storage: CWE-312:CWE-613 (Cleartext Storage of Sensitive Information:Insufficient Session Expiration): code = 1 (msg = 'FAIL:'Expires' header not set:Cache-Control header not set.')
=====> OWASP_SM_004::cookie_via_get: (): code = 0 (msg = 'PASS: Unable to login via GET.')
=====> OWASP_SM_005::csrf: CWE-352 (Cross-Site Request Forgery (CSRF)): code = 1 (msg = 'FAIL:Vulnerable to CSRF Attack (HTTP code 200)')

17 test in 155 secs.

kostenloser Counter

Dan Walsh: execstack on the rampage.

dwalsh@redhat.com — 2011-01-10T20:36:49+00:00

Currently in Fedora 14 execstack avc's seem to be popping up all over the place.

As Uli Drepper describes:

execstack

As the name suggests, this error is raised if a program tries to make its stack (or parts thereof) executable with an mprotect call. This should never, ever be necessary. Stack memory is not executable on most OSes these days and this won't change. Executable stack memory is one of the biggest security problems. An execstack error might in fact be most likely raised by malicious code.

See my overview of security features in Fedora and RHEL for more information, specifically appendix A. It explains how to avoid executable stacks.

What exactly caused this, I am not sure. We have been telling people to search for libraries marked with the execstack flag.

# find /lib -exec execstack -q {} \; -print 2> /dev/null | grep ^X # find /usr/lib -exec execstack -q {} \; -print 2> /dev/null | grep ^X

or # find /lib64 -exec execstack -q {} \; -print 2> /dev/null | grep ^X

# find /usr/lib64 -exec execstack -q {} \; -print 2> /dev/null | grep ^X

If you find one, you can turn off the execstack flag using:

/usr/bin/execstack -c BADLIB.so.

Now you can try the application again and make sure everything continues to work. In most cases the app will work fine and the execstack avc will be eliminated.

John Reiser comments in the bugzilla that if you build a library that is asking for execstack you can fix it:

The package maintainer can turn off execstack when linking the app by
adding "-Wl,-z,noexecstack" to the LDFLAGS (or CFLAGS) in the Makefile.

This takes precedence over .o files or libraries that request execstack,
either deliberately or because some .S assembly language file forgot to

use ".section .note.GNU-stack,"",@progbits" where the empty attribute
string "" turns off execstack.

Finally there has been some indication that the culprit has been libxvidcore...

execstack -c /usr/lib/libxvidcore.so*

Miroslav Grepl: New policies and your help are still needed …

mgrepl — 2011-01-09T22:27:31+00:00

Sunday, another rainy day in the Czech Republic, because of this I started to explore some new features in Fedora15. Bingo, one of them, which I like, “dynamic firewall” is not confined by SELinux.

How can we find it out? It is pretty easy. Either SELinux is complaining and an application/service does not work or just using

# ps -eZ | grep initrc_t

Since initrc_t is the default label we give to procesess started by the init system. If we see a process running as initrc_t, we know the process does not have policy written for it.

So I am seeing:

# service firewalld start
# ps -eZ | grep initrc_t
system_u:system_r:initrc_t:s0 2267 ? 00:00:00 firewalld

Which tells me the service is not confined and I should do more investigation about that and probably I will need to confine this service.

Discovering new unconfined services makes me happy. I will have fine work.

But it also reminds me:

“You should tell people to report these new unconfined applications/services to you, Dan Walsh or bugzilla and thank them they are heads-up”.

The earlier we confine a process the better SELinux will work in the next Fedora release. Maybe some people would like to better understand writing SELinux policy themselves. It is easy too.

Let’s follow my steps:

1. Use the sepolgen command.

# sepolgen –help

Since the firewalld is a standard init daemon.

# sepolgen -t 0 `which firewalld`

Which gives us the firewalld policy files and the firewalld.sh script to install a new policy.

3. Install the firewalld policy.

# sh firewall.sh

4. Do some checks.

# semodule -l | grep firewalld
firewalld 1.0.0

# ls -Z `which firewalld`
-rwxr-xr-x. root root system_u:object_r:firewalld_exec_t:s0 /usr/sbin/firewalld

# ps -eZ | grep firewalld
system_u:system_r:firewalld_t:s0 2679 ? 00:00:00 firewalld

That’s all.

You have the basic SELinux policy for the firewalld which will run as a permissive domain. Now you could just catch all AVC messages, use audit2allow to generate policy

# grep firewalld /var/log/audit/audit.log | audit2allow -R >> firewalld.te
# sh firewalld.sh

and tell me you have great news for us .

Who said SELinux is complicated? :^)

Dominick Grift: Note to self: all the stuff a pulseaudio client needs.

Dominick "domg472" Grift (noreply@blogger.com) — 2010-12-16T03:32:32+00:00

basically i figured out about three scenarios so far:

1: The basics.
Pulseaudio is running normally, and the pulseaudio client needs to make some sound i guess

# manage a pulse-shm file in /dev/shm
manage_files_pattern($1, $2_tmpfs_t, $2_tmpfs_t)
fs_tmpfs_filetrans($1_t, $2_tmpfs_t, file)
fs_getattr_tmpfs($1_t)

# allow the user of the app to manage and relabel that file as well
allow $3 $2_tmpfs_t:file { relabel_file_perms manage_file_perms };

# 1. This add an attribute to the pulse client process so that i can allow each pulse client progress to signull any other pulse client process
# 2, This also adds an attribute to the pulse client tmpfs file so that i can allow each pulse client to read write and delete any others pulse client tmpfs file.
gnome_pulseaudio_client($1, $2)
# read write pulseaudio files in ~/pulse (a directory that is actually owned by gnome settings daemon)
gnome_rw_gsettingsd_pulseaudio_files($1)
# read gnome settings daemon home content for example some symlink in ~/.pulse to a pulseaudio sock file
gnome_read_gsettingsd_home_content($1)
# connect to pulseaudio with a unix stream socket
gnome_stream_connect_gsettingsd_pulseaudio($1, $2)
# search /tmp/pulse-*
gnome_search_gsettingsd_tmp_dirs($1)
# set attributes of ~/.pulse directory
gnome_setattr_gsettingsd_home_dirs($1)

# manage /.cache sound-event-cache files.
xdg_manage_generic_user_cache_files($1)

2: The not so basics.
These pulse client seem to be required to be able to (re) start the main pulseaudio process as well in some particular cases)

# domain transition to the gnome settingsd daemon pulseaudio domain when pulseaudio is executed.
gnome_spec_domtrans_gsettingsd_pulseaudio($1, $2)

3: When pulseaudio is not running.
When you kill pulseaudio and run a pulseaudio client app. It, i guess, expects some pulse audio network functionality because pulse is not running on the local system.

# the pulse client is trying to find pulseaudio on the network i guess...
allow $1 self:netlink_route_socket r_netlink_socket_perms;
allow $1 self:tcp_socket create_socket_perms;
allow $1 self:unix_dgram_socket sendto;

corenet_all_recvfrom_netlabel($1_t)
corenet_all_recvfrom_unlabeled($1_t)
corenet_tcp_bind_generic_node($1_t)
corenet_tcp_sendrecv_generic_if($1_t)
corenet_tcp_sendrecv_generic_node($1_t)
corenet_tcp_connect_pulseaudio_port($1_t)
corenet_tcp_sendrecv_pulseaudio_port($1_t)
corenet_sendrecv_pulseaudio_client_packets($1_t)

# if that isnt enough, the pulseaudio client wants to be a dbus system bus client. Dont ask me why but
its probably looking for pulseaudio run as a dbus system domain or init daemon.
dbus_system_bus_client($1)

..Heck it may even need more like maybe sysnet_read_config, i have not been able to confirm this yet.

The amount of access(policy) a simple gui application needs to be able to spit out a sound with pulseaudio is simply amazing.

Thomas Biege (Security): SAD 1: The Change... and no, we are not in the "House of Flies" here

Thomas (noreply@blogger.com) — 2010-12-06T06:40:54+00:00

I told you that future isn't predictable, that it is dominated by change. So here is what has to change: First (maybe) you!

Power is what most people lack of, people that feel the time for a change is now, or that see the disadvantages in their private and/or working life, often are too powerless. Either their psyche/mind is powerless, or maybe they don't have the executive power, or they do not have ever made the social connections to the right people with the power and mind needed to go a new way.

Well your way of getting your job and more done should be based on a strong mind. If your psychological hygienic is in a bad shape you are lost either way. Stop reading here! Go and change (or start loving!) the ill parts of your character before it is too late.

Will I come to a point in this post. Yes! Read on... :-)

When you are not happy about the security awareness in your company's software department or alike and your boss does not equip you with the power to do the job, the alternative is not to bury your head in the sand but just do it! (Warning: In big companies games are played differently as in small companies, means: Changes in big companies are often not wanted because they introduce risk. "Loser's Game" vs. "Winner's Game")

Of course you cannot go up to the software development department and force them to change their processes to an industry standard (MS SDL, SAMM, etc.). But you can offer the project- or team-leads your HELP. By it I mean you can offer them the parts of your favorite secure code development process that don't cost them much time and money, this means they cost your time of course. Go ahead!

Starting points.

The most less invasive and helpful tasks IMO are:

doing code reviews and filing bugs in their bug tracking system
provide security documents (secure coding, secure design, helpful links) in a wiki or any other internal CMS
offer security trainings directly related to their work
ask project leaders to include you in the application design process

Take care: Don't be a nit-picker or too restrictive. :)

Tips: Presentation, Training

What I found most useful and which is no magic is:

be short
only the most dangerous/important vulnerabilities
don't get lost in details
many examples, try use the team's code
live-sessions

The secure development trainings are really important (I often miss that *sigh*) because you stay in-front of the team and can influence their view on security and the way they develop code in the future. So, be friendly and helpful but also mandatory. Take a look in your soft-skill toolbox to see what techniques might be useful. (I always forget it... unfortunately)

Techniques: The appeal.

Five steps to formulate a clear appeal:

introduction: In the introduction phase you have to set the context by telling your dialog partner (dp) about the topic you are talking about. "I beg you to keep security in mind when developing our applications because security updates cost everybody's time, costs money, and put the customer at risk."
facts: Who should do what when exactly. But take care with the competencies here. Sounding too harsh is too easy. "During my penetration-test I saw simple flaws with high impact like cross-site scripting bugs in our social-network solution. Additionally I also stumbled over design issues like sending credential over the network without using SSL. Please review your code to fix all cross-site scripting vulnerabilities before the next beta-release. Tools for testing and descriptions of the bug as well as possible solutions are described in our Intranet wiki. For the next major version or re-design of our product xyz, I can offer you to be part of it and review the design."
context: People accept and fulfill additional tasks better if they know about he corresponding context. "When we deliver the code as-is with all it's big security holes, hackers will have a lot of fun stealing personal information easily from your customer's servers . We will chip away our image and have additional work releasing security updates. Not releasing bugs is cheaper than providing security updates."
comprehension: Do not ask so called closed questions like "Is everything clear?" or "Is something unclear?" you will get "Yes." respectively "No." as a reflex from your dialog partner. Better use open questions: "I know this kind of vulnerability is very abstract. Where are open questions I can answer for you?", "What can I do for you to make this work?", "Which questions do you have?" And after each question make a long pause, this encourages your dp to react.
acceptance: At the end you need to verify if your appeal was really accepted by your dialog partner. There is a gap between understanding and accepting. The first 4 steps of a clear appeal try to bridge over this gap and at the end you need to verify if you were successful. If you don't like it you can omit this final step and hope for the best. You may also received signals from your dp that shows acceptance or reluctance and adopt the final step based on that. The easiest way would be to ask: "Will you fulfill this task until the next beta-release?" This is of course not the right way if you work on an equal footing. Alternatives might be: "Where can I help you to get this done until next beta-release?" etc.

I should start following my own advises and... also never write a novel. ;)

(for the topic see the following lyrics)

kostenloser Counter

Thomas Biege (Security): Tool: simple XSS fuzzer

Thomas (noreply@blogger.com) — 2010-12-03T07:37:43+00:00

just found none that worked for me and wrote my own. check out fuzz-xss

kostenloser Counter