Crispin Cowan <[email protected]> wrote:
> > This is used, for example, by CacheFiles which has to transparently access
> > the cache on behalf of a process that thinks it is doing, say, NFS
> > accesses with a potentially inappropriate (with respect to accessing the
> > cache) set of security data.
> I'm not sure, but I think that you could do this *much* easier in
> AppArmor using change_profile to switch the NFS Daemon to the profile of
> the requesting process. That still leaves some problems:
NFS Daemon? NFS quite often runs in the context of whichever process issued,
say, a read syscall. It's at this point the cachefiles needs to run, and
using change_profile is I suspect not an option there. Remember: you can't
change the objective profile of the aforementioned process, hence the act_as
pointer.
That said, I don't know what change_profile does.
> However, it seems to me that you have the same problem with SELinux:
> what do you do if the domain/type of the requesting process does not
> exist on the NFS server? How do you ensure a uniform name space of types?
I'm not sure what you're getting at. The security NFS uses to access the
server is separate from the security that cachefiles uses to access the cache.
> > How about I just stick the context in /etc/cachefilesd.conf as a textual
> > configuration item and have the daemon pass that as a string to the
> > cachefiles kernel module, which can then ask LSM if it's valid to set this
> > context as an override, given the daemon's own security context? That
> > seems entirely reasonable to me.
> >
> That semantically maps well to the AppArmor change_profile() API, so
> conceptually it should work.
Okay.
> It would be easier if you did that in user space instead of in the kernel,
Do what in userspace? Parse the context? Validate the context? Or change
the context?
> I don't know if it causes a problem to attempt to kind-of call
> change_profile() from within the kernel. Notably, change_profile can fail,
> so what does your kernel module do when the attempt to change security
> context fails?
The cache aborts and all subsequent operations on that cache bounce and go to
the server instead.
The change of context cannot be done in userspace because to get to a
userspace capable of attempting this operation would itself require a change
of context. Besides, it'd also be inefficient, probably horribly so, to do
all caching ops in userspace.
What I need is an LSM operation to change a task_security struct to have a
specified context. I can then use the task_security struct in all future
cache ops on a cache by pointing task->act_as at it.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
