Looking at SELinux, that doesn't get rid of the permission race because there's
no locking. This may be different for other models.
I was thinking of having steps (2) and (4) not do any checking, but rather
assume that the caller has done the checks before calling the set routines,
possibly by calling the hooks mentioned in (1) and (3).
My main problem is that I don't know how NFSd wants to do things. I suppose
there *ought* to be rules that say what NFSd is allowed to do.
It doesn't matter to cachefiles, but it might matter to other users:-/
That's correct. Let me summarise:
(1) The daemon has an active process security ID (say A). When the daemon
nominates an override process security ID (say B) to be used by the
kernel, the cachefiles module asks the LSM to check that A is allowed to
nominate B for this purpose.
(2) The cachefiles module is given a path under which its cache exists. The
directory at the base of this path has its own security ID (say C).
cachefiles wants to create new files in the cache with the same security
ID as that directory (ie. C).
However, when cachefiles is creating files in the cache, the security of
whatever process is doing the access will be overridden with B, so
cachefiles asks the LSM to check that B is allowed create files as C.
Note that this is an instantaneous check in the cache startup stage. This
allows caching to be aborted early if the security policy does not permit
B to create Cs. Technically this check is superfluous as it's re-checked
each time a vfs_mkdir() or vfs_create() are called.
That depends on what you mean. cachefilesd (the daemon) will be run with a
security label because there's a security model in place.
I don't actually need to access the daemon, but the daemon does need to do
things for which it requires permission grants.
Correct. This is used as an override by any task that accesses the cache
indirectly through the cachefiles module.
The cachefilesd daemon has its own secid with which it accesses the cache
directly. The sets of permissions that must be granted by the module's
override subjective secid and by the daemon's subjective secid aren't
identical.
File and directory objects, yes. The cache is stored on disk as a collection
of files and directories, each of which needs labelling.
Well, they don't technically have to be different. The daemon and the module
can be given the same secid, for instance. However, that secid then grants the
daemon permission to anything the module can, and vice versa.
The third secid is a file label rather than a process label, and so may or may
not have to be different anyway, depending on the model.
David
--
