linux-kernel - Re: [PATCH] Security/sysfs: Enable security xattrs to be set on sysfs files, directories, and symlinks.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1247152602.4398.185.camel@localhost>
Date:	Thu, 09 Jul 2009 11:16:42 -0400
From:	"David P. Quigley" <dpquigl@...ho.nsa.gov>
To:	Casey Schaufler <casey@...aufler-ca.com>
Cc:	jmorris@...ei.org, gregkh@...e.de, sds@...ho.nsa.gov,
	linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [PATCH] Security/sysfs: Enable security xattrs to be set on
 sysfs files, directories, and symlinks.

On Thu, 2009-07-09 at 07:49 -0700, Casey Schaufler wrote:
> 
> Smack depends on the xattr interfaces to inspect and manipulate labels
> on file system objects. Now you have a file system that "supports"
> xattrs, but not the xattr interfaces. What if I want to change the
> label on a sysfs entry? Or even read it? I can't with your scheme.
> 
> You are proposing a one-off hack to solve a particular problem. It
> introduces issues of its own. I don't care that it is clever and
> compact. It's not right.

getfattr -d -m security.* /sys/fs/
getfattr: Removing leading '/' from absolute path names
# file: sys/fs/
security.selinux="system_u:object_r:sysfs_t:s0\000"

# ls -Z
drwxr-xr-x  root root system_u:object_r:sysfs_t:s0     block
drwxr-xr-x  root root system_u:object_r:sysfs_t:s0     bus
drwxr-xr-x  root root system_u:object_r:sysfs_t:s0     class
drwxr-xr-x  root root system_u:object_r:sysfs_t:s0     dev
drwxr-xr-x  root root system_u:object_r:sysfs_t:s0     devices
drwxr-xr-x  root root system_u:object_r:sysfs_t:s0     firmware
drwxr-xr-x  root root system_u:object_r:sysfs_t:s0     fs
drwxr-xr-x  root root system_u:object_r:sysfs_t:s0     hypervisor
drwxr-xr-x  root root system_u:object_r:sysfs_t:s0     kernel
drwxr-xr-x  root root system_u:object_r:sysfs_t:s0     module
drwxr-xr-x  root root system_u:object_r:sysfs_t:s0     power

# setfattr -n security.selinux -v "system_u:object_r:usr_t:s0
\000" /sys/fs/

# ls -Z
drwxr-xr-x  root root system_u:object_r:sysfs_t:s0     block
drwxr-xr-x  root root system_u:object_r:sysfs_t:s0     bus
drwxr-xr-x  root root system_u:object_r:sysfs_t:s0     class
drwxr-xr-x  root root system_u:object_r:sysfs_t:s0     dev
drwxr-xr-x  root root system_u:object_r:sysfs_t:s0     devices
drwxr-xr-x  root root system_u:object_r:sysfs_t:s0     firmware
drwxr-xr-x  root root system_u:object_r:usr_t:s0       fs
drwxr-xr-x  root root system_u:object_r:sysfs_t:s0     hypervisor
drwxr-xr-x  root root system_u:object_r:sysfs_t:s0     kernel
drwxr-xr-x  root root system_u:object_r:sysfs_t:s0     module
drwxr-xr-x  root root system_u:object_r:sysfs_t:s0     power

Now you can argue that it doesn't have the user.* name space or other
name spaces but a file system doesn't have to implement every xattr name
space. We are only implementing the security name space here and your
objection of the xattr interface not being maintained doesn't hold. If
someone wants to go through and do generic xattr support for
non-persistent file systems I welcome that but it's unclear to me what
use case supports that kind of memory usage.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/