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: <1247170786.4398.242.camel@localhost>
Date:	Thu, 09 Jul 2009 16:19:45 -0400
From:	"David P. Quigley" <dpquigl@...ho.nsa.gov>
To:	Greg KH <gregkh@...e.de>
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, 2009-07-09 at 13:12 -0700, Greg KH wrote:
> On Thu, Jul 09, 2009 at 03:28:58PM -0400, David P. Quigley wrote:
> > On Thu, 2009-07-09 at 10:52 -0700, Greg KH wrote:
> > > 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?
> > 
> > A void pointer would suffice if we wanted to store the opaque blob. My
> > argument is that storing that blob is too heavy weight memory wise.
> 
> You could use that void pointer to store your id with no memory
> difference at all, so why would it be "heavy weight"?  It shoud be
> identical, right?
> 
> thanks,
> 
> greg k-h

Not quite. From the memory foot print inside sysfs_dirent it is the same
(baring a pointer being 64-bit on certain platforms) however that
pointer needs to be backed by something. The two current interfaces in
LSM to set an inode security attribute is 1) the xattr, and 2) a secid.
The issue is if we say some people can store the xattr and some can
store a secid I then don't know what hook to call to set the security
information on creation. Which basically boils down to if we have a void
* in sysfs_dirent it has to be the same void * semantics already used
which means it needs to have a string with the label backing it. This
means in the SELinux case I'm now using memory for the string and the
structure in the security server which is a waste. It seems to me though
that It might be possible to make the size of the secid correspond to
the size of a pointer so Casey can return the address of his string as
the secid and we can return the secid. However, it still needs to have
the semantics of the secid and not the opaque void *. 

I could be wrong about this but at the moment the mismatch of semantics
between the two seem to be a problem. If I'm missing anything feel free
to point it out.

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