Stephen Smalley <[email protected]> wrote:
> > (c) A security label that defines the context under which the module
> > operates when accessing the cache. This allows the module, when
> > accessing the cache, to only operate within the bounds of the
> > cache.
>
> Well, only if the module is well-behaved in the first place, since a
> kernel module can naturally bypass SELinux at will. What drives this
> approach vs. exempting the module from SELinux checking via a task flag
> that it raises and lowers around the access (vs. setting and resetting
> the sid around the access to the per-cache module context)?
Christoph objected very strongly to my bypassing of vfs_mkdir() and co, and Al
wasn't to happy about it either. This should allow me, for example, to call
vfs_mkdir() rather than calling the inode op directly as the reason I wasn't
was that I was having to avoid the security checks it made.
Stephen Smalley <[email protected]> wrote:
> > (*) The module will obtain label (c) by reading label (b) from the
> > cachefilesd process when it opens the cachefiles control chardev and
> > then passing it through security_change_sid() to ask the security
> > policy to for label (c).
>
> Do you mean security_transition_sid()? security_change_sid() doesn't
> seem suited to that purpose
That's what Karl said to use.
> What would you use as the target SID and class?
I've no idea. I tried to find out how to use this function from Karl, but he
said I should ask on the list.
> > (3) current->security->sid will be set to label (c) so that
> > vfs_mkdir(), vfs_create() and lookup ops will check for the
> > correct labels.
>
> I think you would want this to be a new ->fssid field instead, and
> adjust SELinux to use it if set for permission checking (which could
> also be leveraged by NFS later).
I could do that. Does it actually gain anything? Or are there good reasons
for not altering current->security->sid? For instance, does that affect the
label seen on /proc/pid/ files?
> Or just use a task flag to disable checking on the module internal accesses.
I could do that too.
> > Point (3) shouldn't cause a cross-thread race as it would appear that
> > the security label can only be changed on single-threaded processes.
> > Attempts to do so on multi-threaded processes are rejected.
>
> I don't quite follow this.
Sorry, I meant that a process can only change its own security label if it's a
single-threaded process. A kernel module can, of course, change the security
label at any time.
> But mutating ->sid could yield unfortunate behavior if e.g. another process
> happens to be sending that task a signal at the same time, so if you go this
> route, you want a ->fssid.
Okay... that seems like a good reason to do use the ->fssid approach. How do I
tell if ->fssid is set? Is zero usable as 'unset'? Alternatively, would it be
reasonable to have ->fssid track ->sid when the latter changes?
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]
