linux-kernel - Re: [PATCH] Security/sysfs: v2 - 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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 20 Aug 2009 07:53:07 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Casey Schaufler <casey@...aufler-ca.com>,
	"David P. Quigley" <dpquigl@...ho.nsa.gov>, jmorris@...ei.org,
	gregkh@...e.de, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, selinux@...ho.nsa.gov
Subject: Re: [PATCH] Security/sysfs: v2 - Enable security xattrs to be set
 on sysfs files, directories, and symlinks.

On Wed, 2009-08-19 at 19:41 -0700, Eric W. Biederman wrote:
> Casey Schaufler <casey@...aufler-ca.com> writes:
> 
> > So I still don't like the way it exposes LSM internal data to the
> > file system code, but given how long it's taking for me to create
> > a better solution I don't think that I can in all fairness say NAK
> > to David Quigley's sysfs patch any longer. I withdraw my objection,
> > while maintaining my reservations.
> 
> Until I see it wired up against another filesystem I retain my
> objections.  When I asked he pretty much told me that it doesn't
> generalize to other filesystems well and it is a sysfs special case.

I think that's a misunderstanding (likely our fault).  As I said, we
already have what we need for getting and setting security xattrs on
in-memory filesystems that pin their inodes, so the only missing bit was
the ability to preserve userspace-set attributes in in-memory
filesystems that can evict their inodes.  And the hooks proposed by
David are generic for that purpose.   You still have to add them to each
such in-memory filesystem that doesn't pin its inodes as each has its
own distinct backing data structure, but you don't need more hooks or a
different approach.

> The way sysctl and proc are wired as special cases into the lsm
> has been a maintenance disaster so far, and I think it a very bad
> idea to add yet another lsm special case, that supports only one
> filesystem.

-- 
Stephen Smalley
National Security Agency

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