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]

Date:	Thu, 9 Jul 2009 10:52:50 -0700
From:	Greg KH <gregkh@...e.de>
To:	"David P. Quigley" <dpquigl@...ho.nsa.gov>
Cc:	jmorris@...ei.org, 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, Jul 09, 2009 at 01:13:33PM -0400, David P. Quigley wrote:
> The issue is that there really aren't any LSM hooks to accommodate that.
> I have a few LSM hooks for the Labeled NFS work which could be used for
> this but it still requires us to store the full xattr value somewhere
> and referencing it in the sysfs_dirent structure.

A void pointer would handle that properly, right?

> The issue here is that there are two ways of presenting security
> information. The first is through the xattr interface which represents
> the security information as an opaque blob which the LSM turns into an
> internal representation. The second which is left over from the early
> days is the secid which I equate to a file handle. The problem I see
> is that the opaque blob (the xattr) is the interface presented to user
> space. It isn't really used internally except to turn it into a data
> structure or to write it to disk for persistence.

That is the way that selinux does it, do the other lsms also handle it
this way?

> The situation we have with sysfs is that there is no persistence for
> labels and the in-core inode maybe evicted so we need a way of
> persisting changes from the default label.

So you put it in the structure you did, which is correct.  You should
also listen to all sysfs netlink messages to be sure to lable things
when they are created, to handle the lack of persistence.

thanks,

greg k-h
--
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/