Messages in this thread | | | Date | Thu, 09 Jul 2009 20:25:39 -0700 | From | Casey Schaufler <> | 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.
| |