--- Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > On Wed, 2007-12-12 at 11:44 -0800, Casey Schaufler wrote: > > --- David Howells <dhowells@xxxxxxxxxx> wrote: > > > > > Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: > > > > > > > What sort of authorization are you thinking of? I would expect > > > > that to have been done by cachefileselinuxcontext (or > > > > cachefilesspiffylsmcontext) up in userspace. If you're going to > > > > rely on userspace applications for policy enforcement they need > > > > to be good enough to count on after all. > > > > > > It can't be done in userspace, otherwise someone using the cachefilesd > > > interface can pass an arbitrary context up. > > > > Yes, but I would expect that interface to be protected (owned by root, > > mode 0400). If /dev/cachefiles has to be publicly accessable make it > > a privileged ioctl. > > Uid 0 != CAP_MAC_OVERRIDE if you configure file caps and such. Yes, but we're talking about writing the configuration information to the kernel, not actually making any access checks with it. I think. What I think we're talking about (and please correct me David if I've stepped into the wrong theatre) is getting the magic secctx that cachefiles will use instead of the secctx that the task would have otherwise. I don't think we're talking about recomputing it on every access, I think David is looking for the blunderbuss secctx that he can use any time he needs one. And it would be CAP_MAC_ADMIN, since you're changing the MAC characteristics of the system, not doing an access check. Casey Schaufler casey@xxxxxxxxxxxxxxxx -- 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.
