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, 09 Jul 2009 20:25:39 -0700
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	"David P. Quigley" <dpquigl@...ho.nsa.gov>
CC:	Greg KH <gregkh@...e.de>, 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.

David P. Quigley wrote:
> On Thu, 2009-07-09 at 10:50 -0700, Greg KH wrote:
>   
>> On Thu, Jul 09, 2009 at 01:26:44PM -0400, David P. Quigley wrote:
>>     
>>> I just read over Casey's comments again and I'm pretty sure we have a
>>> big misunderstanding here. From his initial response it seems that he
>>> thinks that I am exposing the secids to userspace as the way for setting
>>> the labels on files. That isn't true. We are still using the full string
>>> based labels for the userspace interface what the secid is used for is
>>> to allow the kernel to keep track of changes until the sysfs_dirent is
>>> destroyed. 
>>>       
>> Ok, if Casey and others agree that this is the best solution, I'll take
>> it.
>>
>> thanks,
>>
>> greg k-h
>>     
>
>
> I haven't heard from Casey since his last email so I'd hold off on
> taking this until we come to an agreement.

Yeah. Pardon the day job.

>  It seems though from your
> comments in another mail that putting the persistent data into the
> sysfs_dirent is the proper approach and we just need to figure out what
> to put there.
>   

Now that I've really had a chance to review the patches carefully
my worst fears have been put to rest. I don't doubt that what you've
got will work any longer. I do object to using a secid, but I've had
to give in on that before.

If your secid is valid at any given time you have a context (which
is a text string) available at the same time that you can point to.
If this were not true a call to security_xattr_to_secid() could
not be counted on to succeed. You could define
security_xattr_to_secctx() and have it return the Smack value for
Smack and the context for SELinux instead of security_xattr_to_secid().
Sure, you've got a string to maintain, but it had better not be going
away in SELinux, because if it does the secid is going with it. Unless
I recall incorrectly (always a possibility) it has been some time
since the avc could really be considered a cache. I am willing to
bet beers that you could safely point to a mapping somewhere and
not worry much about it.

If not, you've got other performance issues in SELinux.
--
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/