Messages in this thread | | | Date | Fri, 26 Aug 2011 19:05:27 +0300 | Subject | Re: [PATCH] Smack: SMACK_IOCLOADACCESS | From | "Sakkinen, Jarkko" <> |
| |
On Fri, Aug 26, 2011 at 3:50 PM, Eric Paris <eparis@parisplace.org> wrote: > On Fri, Aug 26, 2011 at 1:52 AM, Jarkko Sakkinen > <jarkko.sakkinen@intel.com> wrote: >> IOCTL call for /smack/load that takes access rule in >> the same format as they are written into /smack/load. >> Sets errno to zero if access is allowed and to EACCES >> if not. >> >> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@intel.com> > > [SELinux maintainer here, but Casey knew to already take what I say > with a grain of salt] > > I'm not telling you to do anything differently, just telling you what > SELinux does, and why we do it. SELinux has a file in selinuxfs > called 'access.' The file can be opened and one can write a rule into > the file. One then calls read and gets back a structure which > contains all of the permissions information allowed for the > source/target/class. In SELinux we calculate all of the permissions > for the tuple at once so providing all of the information at once can > make a lot of sense. libselinux provides libraries that will cache > these decisions in the userspace program and quickly answer the same > (or similar) questions later. > > http://userspace.selinuxproject.org/trac/browser/libselinux/src/compute_av.c
Thank you for this information. One thing that concerns me in this approach is the scenario where things serialize to the following sequence:
- Process A does open() - Process B does open() - Process A does write() - Process B does write() - Process A does read() - ... (sequence continues)
What's the end result?
> Shows the userspace side of out "access" interface. Your interface is > good in that it only takes 1 syscall and ours takes 2. Your interface > is bad in that it is ioctl and we are told since birth that we must > hate them no matter what (not that read/write is really any > different). It isn't the same method the only other LSM I know about > uses. It can only every return one value (ok, I know ioctl can be > made to do anything at all)
I'm aware of the fact that IOCTLs should be avoided but on the other hand in this use case I see it as the cleanest possible API that enables clean and simple user space support for access control and has least risk for any side-effects.
> > Anyway, just food for thought.... > > -Eric >
/Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |