xattr

xattr

[Russell Coker]

What is the status of xattr support in 2.5.x?

How is journalling of xattr's being handled?

For correct operation of SE Linux we need to have the xattr that is used for 
the security context be changed atomically, and if a file is created and 
immediately has the xattr set then ideally we would have the file creation 
and the xattr creation in the same journal entry.

Is this possible?  If doing this requires that the file system be mounted with 
data=journal then this will be fine.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: xattr

[Hans Reiser]

Russell Coker wrote:

>What is the status of xattr support in 2.5.x?
>
Please read www.namesys.com/v4/v4.html.  I will be happy to add support 
for desired security attributes using the V4 plugin infrastructure, and 
especially pleased to accept patches that do so.  It is trivially easy 
to compose plugins that commit atomically, and most of them do so by 
default.

I note that we are not listed in spamcop, and thank you for that.  Our 
itanium is now installed, and work has started on moving our mail+web 
server to new hardware and OS version.  When that is complete, the 
mailing list software will be given to a kind volunteer to de-spam.

>
>How is journalling of xattr's being handled?
>
>For correct operation of SE Linux we need to have the xattr that is used for 
>the security context be changed atomically, and if a file is created and 
>immediately has the xattr set then ideally we would have the file creation 
>and the xattr creation in the same journal entry.
>
>Is this possible?  If doing this requires that the file system be mounted with 
>data=journal then this will be fine.
>
>  
>

Namesys generally avoids disturbing the stability of V3 with new 
features.  V4 is coming out this summer, and it is better to focus 
developers on V4.  This is not a categorical rejection, just a gut first 
reaction.

-- 
Hans

Re: xattr

[Chris Mason]

On Mon, 2003-06-16 at 08:26, Russell Coker wrote:
> What is the status of xattr support in 2.5.x?
> 
> How is journalling of xattr's being handled?
> 
> For correct operation of SE Linux we need to have the xattr that is used for 
> the security context be changed atomically, and if a file is created and 
> immediately has the xattr set then ideally we would have the file creation 
> and the xattr creation in the same journal entry.
> 
> Is this possible?  If doing this requires that the file system be mounted with 
> data=journal then this will be fine.

How big are the xattrs you have in mind?  We can get atomic writes of 4k
in length but beyond that things get more difficult.

As for the xattr and the create in the same transaction, that's a little
harder.  We'd probably need a new syscall, or to change the semantics of
the xattr call such that creating an xattr on a file that doesn't exist
also creates the file.

-chris

Re: xattr

[Russell Coker]

On the topic of atomic xattr operations on ReiserFS as needed for the new 
LSM/SE Linux operations.

On Thu, 19 Jun 2003 23:52, Chris Mason wrote:
> How big are the xattrs you have in mind?  We can get atomic writes of 4k
> in length but beyond that things get more difficult.

Most of them will be less than 80 bytes.  They are currently of the form:
user-name:object_r:type

The user-name is the Unix account name which usually isn't much more than 8 
bytes.  The "type" is usually less than 15 bytes (the longest I've used so 
far is 20 bytes).

So the longest value I've used is 38 bytes.

Also they can't be chosen arbitarily by the user.  The user gets some small 
control over the type within a range of types that the administrator permits.
If the administrator permits overly long type names and has to deal with 
non-atomicity as a result then it's their issue.

If you can guarantee atomic operations on 160 byte operations (twice what I 
expect anyone to use) then it'll be fine.

> As for the xattr and the create in the same transaction, that's a little
> harder.  We'd probably need a new syscall, or to change the semantics of
> the xattr call such that creating an xattr on a file that doesn't exist
> also creates the file.

Creating a file by creating the xattr sounds like a bad idea as you can't 
control the Unix permissions of the file.  This isn't much of a big deal with 
SE Linux as the security type determines who can access the file.  But for 
other uses it may be a serious problem.

I agree that we need a new syscall and other people had the same idea before 
either of us.

Maybe ReiserFS could be used as the first implementation of this proposed new 
syscall...

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: xattr

[Chris Mason]

On Thu, 2003-06-19 at 10:46, Russell Coker wrote:
> On the topic of atomic xattr operations on ReiserFS as needed for the new 
> LSM/SE Linux operations.
> 
> On Thu, 19 Jun 2003 23:52, Chris Mason wrote:
> > How big are the xattrs you have in mind?  We can get atomic writes of 4k
> > in length but beyond that things get more difficult.
> 
> Most of them will be less than 80 bytes.  They are currently of the form:
> user-name:object_r:type
> 
> The user-name is the Unix account name which usually isn't much more than 8 
> bytes.  The "type" is usually less than 15 bytes (the longest I've used so 
> far is 20 bytes).
> 
> So the longest value I've used is 38 bytes.
> 

Then data=journal mode will do what you want.  You'll get atomic writes
up to 4k.  If you really don't want data=journal for the rest of the FS,
we can make an option for using data logging on xattr files only.  Jeff
and I had wanted to avoid the complication but it is at least possible.

> Also they can't be chosen arbitarily by the user.  The user gets some small 
> control over the type within a range of types that the administrator permits.
> If the administrator permits overly long type names and has to deal with 
> non-atomicity as a result then it's their issue.
> 
> If you can guarantee atomic operations on 160 byte operations (twice what I 
> expect anyone to use) then it'll be fine.
> 
> > As for the xattr and the create in the same transaction, that's a little
> > harder.  We'd probably need a new syscall, or to change the semantics of
> > the xattr call such that creating an xattr on a file that doesn't exist
> > also creates the file.
> 
> Creating a file by creating the xattr sounds like a bad idea as you can't 
> control the Unix permissions of the file.  This isn't much of a big deal with 
> SE Linux as the security type determines who can access the file.  But for 
> other uses it may be a serious problem.
> 
> I agree that we need a new syscall and other people had the same idea before 
> either of us.
> 
> Maybe ReiserFS could be used as the first implementation of this proposed new 
> syscall...

It would be best to go through Andreas Gruenbacher for xattr API
changes.  He's quite reasonable.

-chris

Re: xattr

[Stephen Smalley]

On Thu, 2003-06-19 at 10:46, Russell Coker wrote:
> On the topic of atomic xattr operations on ReiserFS as needed for the new 
> LSM/SE Linux operations.
> 
> On Thu, 19 Jun 2003 23:52, Chris Mason wrote:
> > How big are the xattrs you have in mind?  We can get atomic writes of 4k
> > in length but beyond that things get more difficult.

4k should be fine.

> > As for the xattr and the create in the same transaction, that's a little
> > harder.  We'd probably need a new syscall, or to change the semantics of
> > the xattr call such that creating an xattr on a file that doesn't exist
> > also creates the file.
> 
> Creating a file by creating the xattr sounds like a bad idea as you can't 
> control the Unix permissions of the file.  This isn't much of a big deal with 
> SE Linux as the security type determines who can access the file.  But for 
> other uses it may be a serious problem.
> 
> I agree that we need a new syscall and other people had the same idea before 
> either of us.
> 
> Maybe ReiserFS could be used as the first implementation of this proposed new 
> syscall...

No, this doesn't have to be done in the same transaction, even under the
old SELinux API.  The setting of the file security label is performed by
the security_inode_post_create/mkdir/... hook call in fs/namei.c, which
is done while the parent directory semaphore is still held.  In the old
API, the desired file security label was specified via
open_secure/mkdir_secure/etc system calls and saved in the per-task
security field for use by the security_inode_post_create/mkdir/...
hook.  In the new API, the desired file security label is specified by
writing it to /proc/pid/attr/fscreate and then performing an ordinary
open()/mkdir()/etc call.  It is an attribute of the task that is applied
to subsequent file creations, similar to the umask.

I seem to be missing a little context; last I looked, reiser in mainline
kernels still didn't provide xattr support.  Will this be changing soon?

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

Re: xattr

[Russell Coker]

On Fri, 20 Jun 2003 00:55, Chris Mason wrote:
> > So the longest value I've used is 38 bytes.
>
> Then data=journal mode will do what you want.  You'll get atomic writes
> up to 4k.  If you really don't want data=journal for the rest of the FS,
> we can make an option for using data logging on xattr files only.  Jeff
> and I had wanted to avoid the complication but it is at least possible.

OK.  Initially just using data=journal should be fine, and even for 
wide-spread use, forcing everyone to use data=journal shouldn't be too much 
of a hardship - although I'm sure that some people will prefer to journal 
only the xattr's.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: xattr

[Chris Mason]

On Thu, 2003-06-19 at 11:10, Stephen Smalley wrote:

> > Creating a file by creating the xattr sounds like a bad idea as you can't 
> > control the Unix permissions of the file.  This isn't much of a big deal with 
> > SE Linux as the security type determines who can access the file.  But for 
> > other uses it may be a serious problem.
> > 
> > I agree that we need a new syscall and other people had the same idea before 
> > either of us.
> > 
> > Maybe ReiserFS could be used as the first implementation of this proposed new 
> > syscall...
> 
> No, this doesn't have to be done in the same transaction, even under the
> old SELinux API.  The setting of the file security label is performed by
> the security_inode_post_create/mkdir/... hook call in fs/namei.c, which
> is done while the parent directory semaphore is still held.  In the old
> API, the desired file security label was specified via
> open_secure/mkdir_secure/etc system calls and saved in the per-task
> security field for use by the security_inode_post_create/mkdir/...
> hook.  In the new API, the desired file security label is specified by
> writing it to /proc/pid/attr/fscreate and then performing an ordinary
> open()/mkdir()/etc call.  It is an attribute of the task that is applied
> to subsequent file creations, similar to the umask.
> 

Ok, so in the new api, the xattr information is available at the time of
the create.  reiserfs would be able to include it all into the same
transaction but doesn't do it right now.

> I seem to be missing a little context; last I looked, reiser in mainline
> kernels still didn't provide xattr support.  Will this be changing soon?

First we need to get the data logging code in (which Hans has agreed
to), getting the xattr code in depends on Hans, Jeff Mahoney will be
maintaining as an external patch otherwise.

-chris

Re: xattr

[Stephen Smalley]

On Thu, 2003-06-19 at 11:21, Chris Mason wrote:
> Ok, so in the new api, the xattr information is available at the time of
> the create.  reiserfs would be able to include it all into the same
> transaction but doesn't do it right now.

This was true of the old API as well; the only difference is whether the
attribute is specified as a parameter to an extended open/mkdir/etc call
or whether it is set separately as a process attribute that is applied
to subsequent ordinary open/mkdir/etc calls.  Including the setxattr in
the same transaction as the create is not strictly necessary, although
it would be nice.  The SELinux API change didn't change the create+set
atomicity, which is still provided by performing the set before the
parent directory semaphore is released.

> First we need to get the data logging code in (which Hans has agreed
> to), getting the xattr code in depends on Hans, Jeff Mahoney will be
> maintaining as an external patch otherwise.

My impression (possibly wrong) is that Hans prefers a EA-as-file model,
which I understand is also the Solaris model.  The key question then
becomes whether mainline reiser{3,4} will ever support the xattr inode
operations (e.g. implementing them as reads/writes of the EA files
associated with the inode).  If not, then neither the SELinux "module"
nor the SELinux userland will be able to access file security attributes
on reiser{3,4} in the same manner as on ext[23], xfs, or jfs.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

Re: xattr

[Chris Mason]

On Thu, 2003-06-19 at 13:25, Stephen Smalley wrote:
> On Thu, 2003-06-19 at 11:21, Chris Mason wrote:
> > Ok, so in the new api, the xattr information is available at the time of
> > the create.  reiserfs would be able to include it all into the same
> > transaction but doesn't do it right now.
> 
> This was true of the old API as well; the only difference is whether the
> attribute is specified as a parameter to an extended open/mkdir/etc call
> or whether it is set separately as a process attribute that is applied
> to subsequent ordinary open/mkdir/etc calls.  Including the setxattr in
> the same transaction as the create is not strictly necessary, although
> it would be nice.  The SELinux API change didn't change the create+set
> atomicity, which is still provided by performing the set before the
> parent directory semaphore is released.
> 

Ok, I get it.  You would need a special reiserfs xattr add on patch to
get the atomicity right.

> > First we need to get the data logging code in (which Hans has agreed
> > to), getting the xattr code in depends on Hans, Jeff Mahoney will be
> > maintaining as an external patch otherwise.
> 
> My impression (possibly wrong) is that Hans prefers a EA-as-file model,
> which I understand is also the Solaris model.  The key question then
> becomes whether mainline reiser{3,4} will ever support the xattr inode
> operations (e.g. implementing them as reads/writes of the EA files
> associated with the inode).  If not, then neither the SELinux "module"
> nor the SELinux userland will be able to access file security attributes
> on reiser{3,4} in the same manner as on ext[23], xfs, or jfs.

The reiserfsv3 xattr patches maintained by SuSE implement the xattr api
(acl.bestbits.at).  The xattrs happen to be implemented as individual
files on disk because reiserfs is so well suited for it, and because it
allowed Jeff to code them without changing the v3 disk format.

But, these files are only available through the xattr api right now, and
they are not visible via tools like ls etc.

Not sure how namesys is doing things in version 4, but I'd bet they are 
willing to talk about making it work with SELinux.

-chris

Re: xattr

[Stephen Smalley]

On Thu, 2003-06-19 at 14:06, Chris Mason wrote:
> Ok, I get it.  You would need a special reiserfs xattr add on patch to
> get the atomicity right.

I don't think so.  If you crash between the create and the setxattr,
you'll just have an empty file that has no xattr, which will effectively
just cause it to be mapped to a default security label until an xattr is
set administratively.  No real harm.

> The reiserfsv3 xattr patches maintained by SuSE implement the xattr api
> (acl.bestbits.at).  The xattrs happen to be implemented as individual
> files on disk because reiserfs is so well suited for it, and because it
> allowed Jeff to code them without changing the v3 disk format.
> 
> But, these files are only available through the xattr api right now, and
> they are not visible via tools like ls etc.

Which is what we would want.  SELinux userland will only access them via
xattr API (actually via a SELinux API wrapped around the xattr calls to
encapsulate the use of xattr and the specific xattr name).

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

how to fix the file system which has a dangling file?

[bmoon]

Hello!

I accidently ran a novice application to create a big file, that was bigger
than the size of available disk space.

So it created a dangling file which can not be removed, even I can not
remove the directory including that file.

I ran "fsck -f" , it did not help.

It is on EX2 file system.

Please provide me any idea to remove it.

Thanks,

Bo

Re: xattr

[Hans Reiser]

Chris Mason wrote:

>On Mon, 2003-06-16 at 08:26, Russell Coker wrote:
>  
>
>>What is the status of xattr support in 2.5.x?
>>
>>How is journalling of xattr's being handled?
>>
>>For correct operation of SE Linux we need to have the xattr that is used for 
>>the security context be changed atomically, and if a file is created and 
>>immediately has the xattr set then ideally we would have the file creation 
>>and the xattr creation in the same journal entry.
>>
>>Is this possible?  If doing this requires that the file system be mounted with 
>>data=journal then this will be fine.
>>    
>>
>
>How big are the xattrs you have in mind?  We can get atomic writes of 4k
>in length but beyond that things get more difficult.
>
it is complete trivial to do it in reiser4.

>
>As for the xattr and the create in the same transaction, that's a little
>harder.  
>
equally easy in reiser4.

>We'd probably need a new syscall, or to change the semantics of
>the xattr call such that creating an xattr on a file that doesn't exist
>also creates the file.
>
>-chris
>
>
>
>
>  
>
V3 should not have new features added to it.  It needs to be zero 
defect, and avoiding new features is the only way.

-- 
Hans

Re: xattr

[James Carter]

On Mon, 2003-12-01 at 22:33, Russell Coker wrote:
> Please send me the patch Steve mentioned:

Here is the ext2 patch.  

This patch is relative to linux 2.4.22 with the
ea+acl+nfsacl-2.4.22-0.8.61.diff applied.  (It will also apply cleanly
with the ea and acl patches applied.)  It is a backport of the
extended attribute handler in the 2.5/6 kernel for security modules.

For the 2.4.21 kernel I used the ea+acl+nfsacl because that was the only
patch available, in the 2.4.22 kernel I used only the ea patch, since
that was all that was needed to support SELinux.  For 2.4.23, I plan on
going back to the full patch (or at least ea and acl) since there seems
to be interest in using acls along with SELinux.

 Documentation/Configure.help |   10 ++++++
 fs/Config.in                 |    2 +
 fs/ext2/Makefile             |    1 
 fs/ext2/super.c              |    8 ++++
 fs/ext2/xattr_security.c     |   69 +++++++++++++++++++++++++++++++++++++++++++
 include/linux/ext2_xattr.h   |   21 +++++++++++++
 6 files changed, 110 insertions(+), 1 deletion(-)

Index: linux-2.4/Documentation/Configure.help
diff -u linux-2.4/Documentation/Configure.help:1.1.1.2 linux-2.4/Documentation/Configure.help:1.10
--- linux-2.4/Documentation/Configure.help:1.1.1.2	Mon Jul 28 14:33:23 2003
+++ linux-2.4/Documentation/Configure.help	Fri Sep  5 16:10:47 2003
@@ -15653,6 +15653,16 @@
 
   If unsure, say N.
 
+Ext2 Security Labels
+CONFIG_EXT2_FS_SECURITY
+  Security labels support alternative access control models
+  implemented by security modules like SELinux.  This option
+  enables an extended attribute handler for file security
+  labels in the ext2 filesystem.
+
+  If you are not using a security module that requires using
+  extended attributes for file security labels, say N.
+
 Ext2 POSIX Access Control Lists
 CONFIG_EXT2_FS_POSIX_ACL
   POSIX Access Control Lists (ACLs) support permissions for users and
Index: linux-2.4/fs/Config.in
diff -u linux-2.4/fs/Config.in:1.1.1.2 linux-2.4/fs/Config.in:1.7
--- linux-2.4/fs/Config.in:1.1.1.2	Mon Jul 28 14:18:20 2003
+++ linux-2.4/fs/Config.in	Tue Jul 29 16:00:34 2003
@@ -104,6 +104,8 @@
     CONFIG_EXT2_FS_XATTR_USER $CONFIG_EXT2_FS_XATTR
 dep_bool '    Ext2 trusted extended attributes' \
     CONFIG_EXT2_FS_XATTR_TRUSTED $CONFIG_EXT2_FS_XATTR
+dep_bool '    Ext2 security labels' \
+    CONFIG_EXT2_FS_SECURITY $CONFIG_EXT2_FS_XATTR
 dep_bool '    Ext2 POSIX Access Control Lists' \
 	CONFIG_EXT2_FS_POSIX_ACL $CONFIG_EXT2_FS_XATTR
 
Index: linux-2.4/fs/ext2/Makefile
diff -u linux-2.4/fs/ext2/Makefile:1.1.1.2 linux-2.4/fs/ext2/Makefile:1.3
--- linux-2.4/fs/ext2/Makefile:1.1.1.2	Mon Jul 28 14:18:34 2003
+++ linux-2.4/fs/ext2/Makefile	Tue Jul 29 16:00:44 2003
@@ -17,6 +17,7 @@
 obj-$(CONFIG_EXT2_FS_XATTR) += xattr.o
 obj-$(CONFIG_EXT2_FS_XATTR_USER) += xattr_user.o
 obj-$(CONFIG_EXT2_FS_XATTR_TRUSTED) += xattr_trusted.o
+obj-$(CONFIG_EXT2_FS_SECURITY) += xattr_security.o
 obj-$(CONFIG_EXT2_FS_POSIX_ACL) += acl.o
 
 include $(TOPDIR)/Rules.make
Index: linux-2.4/fs/ext2/super.c
diff -u linux-2.4/fs/ext2/super.c:1.1.1.2 linux-2.4/fs/ext2/super.c:1.3
--- linux-2.4/fs/ext2/super.c:1.1.1.2	Mon Jul 28 14:18:34 2003
+++ linux-2.4/fs/ext2/super.c	Tue Jul 29 16:00:44 2003
@@ -869,14 +869,20 @@
 	error = init_ext2_xattr_trusted();
 	if (error)
 		goto fail2;
-	error = init_ext2_acl();
+	error = init_ext2_xattr_security();
 	if (error)
 		goto fail3;
+	error = init_ext2_acl();
+	if (error)
+		goto fail4;
+
 	error = register_filesystem(&ext2_fs_type);
 	if (!error)
 		return 0;
 
 	exit_ext2_acl();
+fail4:
+	exit_ext2_xattr_security();
 fail3:
 	exit_ext2_xattr_trusted();
 fail2:
Index: linux-2.4/fs/ext2/xattr_security.c
diff -u /dev/null linux-2.4/fs/ext2/xattr_security.c:1.2
--- /dev/null	Tue Sep 23 10:30:46 2003
+++ linux-2.4/fs/ext2/xattr_security.c	Thu Jun 26 15:32:56 2003
@@ -0,0 +1,69 @@
+/*
+ * linux/fs/ext2/xattr_security.c
+ * Handler for storing security labels as extended attributes.
+ */
+
+#include <linux/module.h>
+#include <linux/string.h>
+#include <linux/fs.h>
+/* #include <linux/smp_lock.h> */
+#include <linux/ext2_fs.h>
+#include <linux/ext2_xattr.h>
+
+#define XATTR_SECURITY_PREFIX "security."
+
+static size_t
+ext2_xattr_security_list(char *list, struct inode *inode,
+			const char *name, int name_len)
+{
+	const int prefix_len = sizeof(XATTR_SECURITY_PREFIX)-1;
+
+	if (list) {
+		memcpy(list, XATTR_SECURITY_PREFIX, prefix_len);
+		memcpy(list+prefix_len, name, name_len);
+		list[prefix_len + name_len] = '\0';
+	}
+	return prefix_len + name_len + 1;
+}
+
+static int
+ext2_xattr_security_get(struct inode *inode, const char *name,
+		       void *buffer, size_t size)
+{
+	if (strcmp(name, "") == 0)
+		return -EINVAL;
+	return ext2_xattr_get(inode, EXT2_XATTR_INDEX_SECURITY, name,
+			      buffer, size);
+}
+
+static int
+ext2_xattr_security_set(struct inode *inode, const char *name,
+		       const void *value, size_t size, int flags)
+{
+	if (strcmp(name, "") == 0)
+		return -EINVAL;
+	return ext2_xattr_set(inode, EXT2_XATTR_INDEX_SECURITY, name,
+			      value, size, flags);
+}
+
+struct ext2_xattr_handler ext2_xattr_security_handler = {
+	.prefix	= XATTR_SECURITY_PREFIX,
+	.list	= ext2_xattr_security_list,
+	.get	= ext2_xattr_security_get,
+	.set	= ext2_xattr_security_set,
+};
+
+int __init
+init_ext2_xattr_security(void)
+{
+	return ext2_xattr_register(EXT2_XATTR_INDEX_SECURITY,
+				   &ext2_xattr_security_handler);
+}
+
+void
+exit_ext2_xattr_security(void)
+{
+	ext2_xattr_unregister(EXT2_XATTR_INDEX_SECURITY,
+			      &ext2_xattr_security_handler);
+}
+
Index: linux-2.4/include/linux/ext2_xattr.h
diff -u linux-2.4/include/linux/ext2_xattr.h:1.1.1.2 linux-2.4/include/linux/ext2_xattr.h:1.5
--- linux-2.4/include/linux/ext2_xattr.h:1.1.1.2	Mon Jul 28 14:20:05 2003
+++ linux-2.4/include/linux/ext2_xattr.h	Wed Jul 30 15:58:10 2003
@@ -22,6 +22,7 @@
 #define EXT2_XATTR_INDEX_POSIX_ACL_ACCESS	2
 #define EXT2_XATTR_INDEX_POSIX_ACL_DEFAULT	3
 #define EXT2_XATTR_INDEX_TRUSTED		4
+#define EXT2_XATTR_INDEX_SECURITY		6
 
 struct ext2_xattr_header {
 	__u32	h_magic;	/* magic number for identification */
@@ -175,6 +176,26 @@
 }
 
 # endif  /* CONFIG_EXT2_FS_XATTR_TRUSTED */
+
+# ifdef CONFIG_EXT2_FS_SECURITY
+
+extern int init_ext2_xattr_security(void) __init;
+extern void exit_ext2_xattr_security(void);
+
+# else  /* CONFIG_EXT2_FS_SECURITY */
+
+static inline int
+init_ext2_xattr_security(void)
+{
+	return 0;
+}
+
+static inline void
+exit_ext2_xattr_security(void)
+{
+}
+
+#endif	/* CONFIG_EXT2_FS_SECURITY */
 
 #endif  /* __KERNEL__ */
 


-- 
James Carter <jwcart2@epoch.ncsc.mil>
National Security Agency

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: xattr

[James Carter]

On Mon, 2003-12-01 at 22:33, Russell Coker wrote:
> Please send me the patch Steve mentioned:

Here is the ext3 patch.  

This patch is relative to linux 2.4.22 with the
ea+acl+nfsacl-2.4.22-0.8.61.diff applied.  (It will also apply cleanly
with the ea and acl patches applied.)  It is a backport of the
extended attribute handler in the 2.5/6 kernel for security modules.

For the 2.4.21 kernel I used the ea+acl+nfsacl because that was the only
patch available, in the 2.4.22 kernel I used only the ea patch, since
that was all that was needed to support SELinux.  For 2.4.23, I plan on
going back to the full patch (or at least ea and acl) since there seems
to be interest in using acls along with SELinux.

 Documentation/Configure.help |   10 ++++++
 fs/Config.in                 |    2 +
 fs/ext3/Makefile             |    1 
 fs/ext3/super.c              |    8 ++++-
 fs/ext3/xattr_security.c     |   68 +++++++++++++++++++++++++++++++++++++++++++
 include/linux/ext3_xattr.h   |   23 ++++++++++++++
 6 files changed, 111 insertions(+), 1 deletion(-)

Index: linux-2.4/Documentation/Configure.help
diff -u linux-2.4/Documentation/Configure.help:1.1.1.2 linux-2.4/Documentation/Configure.help:1.10
--- linux-2.4/Documentation/Configure.help:1.1.1.2	Mon Jul 28 14:33:23 2003
+++ linux-2.4/Documentation/Configure.help	Fri Sep  5 16:10:47 2003
@@ -15722,6 +15722,16 @@
 
   If unsure, say N.
 
+Ext3 Security Labels
+CONFIG_EXT3_FS_SECURITY
+  Security labels support alternative access control models
+  implemented by security modules like SELinux.  This option
+  enables an extended attribute handler for file security
+  labels in the ext3 filesystem.
+
+  If you are not using a security module that requires using
+  extended attributes for file security labels, say N.
+
 Ext3 POSIX Access Control Lists
 CONFIG_EXT3_FS_POSIX_ACL
   POSIX Access Control Lists (ACLs) support permissions for users and
Index: linux-2.4/fs/Config.in
diff -u linux-2.4/fs/Config.in:1.1.1.2 linux-2.4/fs/Config.in:1.7
--- linux-2.4/fs/Config.in:1.1.1.2	Mon Jul 28 14:18:20 2003
+++ linux-2.4/fs/Config.in	Tue Jul 29 16:00:34 2003
@@ -36,6 +36,8 @@
     CONFIG_EXT3_FS_XATTR_USER $CONFIG_EXT3_FS_XATTR
 dep_bool '    Ext3 trusted extended attributes' \
     CONFIG_EXT3_FS_XATTR_TRUSTED $CONFIG_EXT3_FS_XATTR
+dep_bool '    Ext3 security labels' \
+    CONFIG_EXT3_FS_SECURITY $CONFIG_EXT3_FS_XATTR
 dep_bool '    Ext3 POSIX Access Control Lists' \
     CONFIG_EXT3_FS_POSIX_ACL $CONFIG_EXT3_FS_XATTR
 # CONFIG_JBD could be its own option (even modular), but until there are
Index: linux-2.4/fs/ext3/Makefile
diff -u linux-2.4/fs/ext3/Makefile:1.1.1.2 linux-2.4/fs/ext3/Makefile:1.5
--- linux-2.4/fs/ext3/Makefile:1.1.1.2	Mon Jul 28 14:19:13 2003
+++ linux-2.4/fs/ext3/Makefile	Tue Jul 29 16:00:45 2003
@@ -17,6 +17,7 @@
 obj-$(CONFIG_EXT3_FS_XATTR) += xattr.o
 obj-$(CONFIG_EXT3_FS_XATTR_USER) += xattr_user.o
 obj-$(CONFIG_EXT3_FS_XATTR_TRUSTED) += xattr_trusted.o
+obj-$(CONFIG_EXT3_FS_SECURITY) += xattr_security.o
 obj-$(CONFIG_EXT3_FS_POSIX_ACL) += acl.o
 
 include $(TOPDIR)/Rules.make
Index: linux-2.4/fs/ext3/super.c
diff -u linux-2.4/fs/ext3/super.c:1.1.1.2 linux-2.4/fs/ext3/super.c:1.3
--- linux-2.4/fs/ext3/super.c:1.1.1.2	Mon Jul 28 14:19:12 2003
+++ linux-2.4/fs/ext3/super.c	Tue Jul 29 16:00:45 2003
@@ -1882,14 +1882,20 @@
 	error = init_ext3_xattr_trusted();
 	if (error)
 		goto fail2;
-	error = init_ext3_acl();
+	error = init_ext3_xattr_security();
 	if (error)
 		goto fail3;
+	error = init_ext3_acl();
+	if (error)
+		goto fail4;
+
 	error = register_filesystem(&ext3_fs_type);
 	if (!error)
 		return 0;
 	
 	exit_ext3_acl();
+fail4:
+	exit_ext3_xattr_security();
 fail3:
 	exit_ext3_xattr_trusted();
 fail2:
Index: linux-2.4/fs/ext3/xattr_security.c
diff -u /dev/null linux-2.4/fs/ext3/xattr_security.c:1.2
--- /dev/null	Tue Sep 23 10:30:46 2003
+++ linux-2.4/fs/ext3/xattr_security.c	Thu Jun 26 14:48:32 2003
@@ -0,0 +1,68 @@
+/*
+ * linux/fs/ext3/xattr_security.c
+ * Handler for storing security labels as extended attributes.
+ */
+
+#include <linux/module.h>
+#include <linux/string.h>
+#include <linux/fs.h>
+#include <linux/ext3_jbd.h>
+#include <linux/ext3_fs.h>
+#include <linux/ext3_xattr.h>
+
+#define XATTR_SECURITY_PREFIX "security."
+
+static size_t
+ext3_xattr_security_list(char *list, struct inode *inode,
+		    const char *name, int name_len)
+{
+	const int prefix_len = sizeof(XATTR_SECURITY_PREFIX)-1;
+
+	if (list) {
+		memcpy(list, XATTR_SECURITY_PREFIX, prefix_len);
+		memcpy(list+prefix_len, name, name_len);
+		list[prefix_len + name_len] = '\0';
+	}
+	return prefix_len + name_len + 1;
+}
+
+static int
+ext3_xattr_security_get(struct inode *inode, const char *name,
+		       void *buffer, size_t size)
+{
+	if (strcmp(name, "") == 0)
+		return -EINVAL;
+	return ext3_xattr_get(inode, EXT3_XATTR_INDEX_SECURITY, name,
+			      buffer, size);
+}
+
+static int
+ext3_xattr_security_set(struct inode *inode, const char *name,
+		       const void *value, size_t size, int flags)
+{
+	if (strcmp(name, "") == 0)
+		return -EINVAL;
+	return ext3_xattr_set(inode, EXT3_XATTR_INDEX_SECURITY, name,
+			      value, size, flags);
+}
+
+struct ext3_xattr_handler ext3_xattr_security_handler = {
+	.prefix	= XATTR_SECURITY_PREFIX,
+	.list	= ext3_xattr_security_list,
+	.get	= ext3_xattr_security_get,
+	.set	= ext3_xattr_security_set,
+};
+
+int __init
+init_ext3_xattr_security(void)
+{
+	return ext3_xattr_register(EXT3_XATTR_INDEX_SECURITY,
+				   &ext3_xattr_security_handler);
+}
+
+void
+exit_ext3_xattr_security(void)
+{
+	ext3_xattr_unregister(EXT3_XATTR_INDEX_SECURITY,
+			      &ext3_xattr_security_handler);
+}
Index: linux-2.4/include/linux/ext3_xattr.h
diff -u linux-2.4/include/linux/ext3_xattr.h:1.1.1.2 linux-2.4/include/linux/ext3_xattr.h:1.6
--- linux-2.4/include/linux/ext3_xattr.h:1.1.1.2	Mon Jul 28 14:20:05 2003
+++ linux-2.4/include/linux/ext3_xattr.h	Wed Jul 30 15:58:10 2003
@@ -22,6 +22,7 @@
 #define EXT3_XATTR_INDEX_POSIX_ACL_ACCESS	2
 #define EXT3_XATTR_INDEX_POSIX_ACL_DEFAULT	3
 #define EXT3_XATTR_INDEX_TRUSTED		4
+#define EXT3_XATTR_INDEX_SECURITY		6
 
 struct ext3_xattr_header {
 	__u32	h_magic;	/* magic number for identification */
@@ -178,5 +179,27 @@
 
 #endif  /* CONFIG_EXT3_FS_XATTR_TRUSTED */
 
+# ifdef CONFIG_EXT3_FS_SECURITY
+
+extern int init_ext3_xattr_security(void) __init;
+extern void exit_ext3_xattr_security(void);
+
+# else  /* CONFIG_EXT3_FS_SECURITY */
+
+static inline int
+init_ext3_xattr_security(void)
+{
+	return 0;
+}
+
+static inline void
+exit_ext3_xattr_security(void)
+{
+}
+
+#endif	/* CONFIG_EXT3_FS_SECURITY */
+
 #endif  /* __KERNEL__ */
+
+
 


-- 
James Carter <jwcart2@epoch.ncsc.mil>
National Security Agency

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.