On Mon, 2009-04-20 at 14:11 -0400, Eric Paris wrote: > On Mon, 2009-04-20 at 13:35 -0400, Chad Sellers wrote: > > On 4/20/09 1:21 PM, "Eric Paris" <eparis@xxxxxxxxxx> wrote: > > <snip> > > > > > > I'm going to spend a couple minutes and try to prototype an all in > > > kernel solution such that on access() we will check the permission: > > > > > > allow process_t file_t:file read > > > > > > if there is a dontaudit rule for EITHER "read" or "access_read" we will > > > NOT print an avc denial. > > > > > > on the actual usage we will ONLY check for the "read" dontaudit. > > > > > That sounds like a better solution than anything we've talked about so far. > > It would mean the policy author would only have to worry about the access_* > > perms if they cared about the issue they're designed to solve. Hopefully you > > can find an acceptable way to pull it off in the kernel. I'm rooting for > > you! > > So James, Stephen what do we think of something like this? Lot of code > bloat and pain on the access+denial path, but shouldn't hurt us any in > the hot case... > > --- > diff --git a/fs/open.c b/fs/open.c > index 377eb25..485cfd8 100644 > --- a/fs/open.c > +++ b/fs/open.c > @@ -493,7 +493,7 @@ SYSCALL_DEFINE3(faccessat, int, dfd, const char __user *, filename, int, mode) > goto out_path_release; > } > > - res = inode_permission(inode, mode | MAY_ACCESS); > + res = inode_access_permission(inode, mode | MAY_ACCESS); I had forgotten that there is already a MAY_ACCESS flag defined and used by the vfs. So why can't we just pass that on to the security modules and use that to distinguish access(2) from open(2)? Looks like it gets used on chdir(2) and chroot(2) as well, which is unfortunate, and I don't quite understand why. Maybe we need to look back at the origins of the MAY_ACCESS flag and its rationale. > /* SuS v2 requires we report a read only fs too */ > if (res || !(mode & S_IWOTH) || special_file(inode->i_mode)) > goto out_path_release; -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
