1 |
For anyone that is interested, I've created a patch to XFS that adds the |
2 |
security.* extended attribute namespace needed by SElinux. |
3 |
|
4 |
I've created two patches. |
5 |
This (http://www.glines.com/xfs.patch.bz2) contains only the changes too |
6 |
XFS. |
7 |
This (http://www.glines.com/2.4.21-xfs+selinux.patch.bz2) can be applied |
8 |
against a vanilla 2.4.21 kernel and will give you SElinux and a SElinux |
9 |
friendly XFS. |
10 |
|
11 |
Internally XFS distinguishes between user and trusted attributes via a flag |
12 |
(XFS_ATTR_ROOT). If just modified xfs_iops.c is modified, the security.* |
13 |
attributes also appear in the user.* namespace. I saw two ways fix this. |
14 |
|
15 |
One option was to store the security.* attributes in either the trusted or |
16 |
user namespace. Then hack the XFS internals so that any user.security.* or |
17 |
trusted.security.* attribute would not appear in trusted or user but would |
18 |
appear as if it was in the security namespace. I didn't like this option |
19 |
because it was going to be a more complicated code chage. That, and it just |
20 |
felt like a hack. |
21 |
|
22 |
The other option was to add true support for the security namespace. This |
23 |
would require adding a flag to the attribute's flags bitfield. I liked this |
24 |
option because it was simpler to code and just looked cleaner. The bit slot |
25 |
I chose appears to be unused. At least I could find no place in the code |
26 |
that uses it. If security.* attributes are set and the filesystem is then |
27 |
mounted with a standard XFS kernel, those attributes will appear in the user |
28 |
namespace. |
29 |
|
30 |
I haven't looked at xfsdump/xfsrestore so I don't know if they will require |
31 |
changes. I'm hoping that they take the flags field whole and don't do |
32 |
anything with it that could disrupt the new XFS_ATTR_SECURITY bit. |
33 |
|
34 |
-Tad |
35 |
|
36 |
|
37 |
-- |
38 |
gentoo-hardened@g.o mailing list |