[lkml]   [2006]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Security issues with local filesystem caching
    Stephen Smalley <> 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 <> 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?

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-11-01 16:39    [W:0.022 / U:97.560 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site