linux-kernel - Re: VFS and LSM issues

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: <5488804E.8040404@tycho.nsa.gov>
Date:	Wed, 10 Dec 2014 12:18:06 -0500
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	Krzysztof Opasiak <k.opasiak@...sung.com>,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, casey@...aufler-ca.com
CC:	jlbec@...lplan.org,
	"'Andrzej Pietrasiewicz'" <andrzej.p@...sung.com>,
	gregkh@...uxfoundation.org,
	"'Michal Nazarewicz'" <mina86@...a86.com>,
	"'Robert Baldyga'" <r.baldyga@...sung.com>,
	Rafal Krypa <r.krypa@...sung.com>,
	Tomasz Swierczek <t.swierczek@...sung.com>,
	"'Karol Lewandowski'" <k.lewandowsk@...sung.com>,
	"'Marek Szyprowski'" <m.szyprowski@...sung.com>,
	"'Stanislaw Wadas'" <s.wadas@...sung.com>, kopasiak90@...il.com,
	'Łukasz Stelmach' <l.stelmach@...sung.com>
Subject: Re: VFS and LSM issues

On 12/08/2014 12:04 PM, Krzysztof Opasiak wrote:
> Dear All,
> 
> I'm Krzysztof Opasiak from SRPOL (Samsung). I'm working on USB support
> in Tizen and mainline. In those works we use two Virtual File Systems
> - ConfigFS and FunctionFS. Recently I have tried to use them with
> SMACK and I ran into a few issues. Most of them looks to be a generic
> problem with many FS and LSM. You can find description of those issues
> and my research just below in 3 points. I'm not a VFS/LSM specialist so
> your help is very welcome;)
> 
> 1) Issues with function FS
> 
> It's a VFS which allow to provide custom USB function as userspace
> program. I know that may be quite new for you so let's define this as
> a VFS which works as follow:
> 
> $ modprobe g_ffs
> $ mkdir /tmp/mount_root
> $ mount none -t functionfs /tmp/mount_root
> $ ls /tmp/mount_root
> ep0
> 
> # now we run our program which writes some data to ep0
> #  and based on this kernel creates epX
> # you can find one in tools/usb/ffs-test.c
> 
> $ ./my_program /tmp/mount_root &
> $ ls /tmp/mount_root
> ep0 ep1 ep2
> 
> Ok so now we would like to use this together with smack. Especially
> with smackfsdef mount option. First two steps go as above and then:
> 
> $ mount none -t functionfs -o smackfsdef=my_label /tmp/mount_root
> $ ls -Z /tmp/mount_root/
>  _ ep0
> 
> Ops! Some bug here we requested to use my_label but we got _. When we
> run our program, rest of epX will get desired label (my_label). I have
> started to dig in kernel to find what happen and probably I found out
> where is a problem. Let's look to mount_fs() code which is executed
> during mount:
> 
> struct dentry *
> mount_fs(struct file_system_type *type, int flags, const char *name,
> void *data)
> {
> (...)
> 	root = type->mount(type, flags, name, data);
> (...)
> 	error = security_sb_kern_mount(sb, flags, secdata);
> (...)
> }
> 
> So what is important here is the order of operations. First is
> executed mount ops provided by selected file system. During this mount
> procedure functionfs executes new_inode(sb) to allocate inode for ep0
> which should appear directly after mount. After returning from mount
> function we execute security_sb_kern_mount() where we *parse the mount
> options* and sets the value for lsm specific structures for example we
> store the label passed in smackfsdef.
> 
> The problem here is order of calls because first we call mount for
> given fs where we create a file and after this we fill security
> structures with security mount options. While creating file in mount
> callback super block is filled only with default values for security
> so ep0 has _ label. This looks like a generic issue for all VFS which
> creates indoes before or in their mount procedure.
> 
> I'm not sure if we can simply move security_sb_kern_mount() above
> mount for specific fs, do we?

No.  Look at SELinux for an example. It puts the inode security
structures into a list and then initializes them during
security_sb_kern_mount(), both to handle labeling of inodes initialized
before first policy load and to handle inodes created during ->mount().
 In particular, look at the tail of sb_finish_set_opts() in
security/selinux/hooks.c.  As SELinux has been handling this for a long
time, I would call this a bug in Smack, not in the VFS LSM hooks.

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