Re: Security issues with local filesystem caching

On Wed, 2006-11-01 at 15:34 +0000, David Howells wrote:
Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
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.

I wasn't suggesting bypassing the vfs helpers; I was only asking what
motivated the approach of substituting a different SID for the
permission checks vs. using a task flag to disable the permission
checking entirely when the module performs an internal access. The task
flag approach is simpler and avoids the need to set up a label and
policy for the module's internal accesses, which should always succeed
if the module is operating correctly. The only reason to apply a check
on the module's internal accesses is if you want policy to help
safeguard the module against unintentional access attempts to e.g. the
wrong cache or a file outside of the cache. And even that is only a
discretionary safeguard wrt the module - it still relies on the module
to not bypass the security hooks and to set the SID correctly for the
cache it wants to access.

Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
Do you mean security_transition_sid()? security_change_sid() doesn't
seem suited to that purpose

That's what Karl said to use.

I think security_transition_sid() is more appropriate if you use this
approach.

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.

In normal practice, one passes the task SID as the first argument, the
SID of a related object as the second argument, and the class of object
for which you are computing a SID as the third argument. For program
execution, this takes the form of the current task SID, the executable
file SID, and the process class, and computes the new task SID of the
transformed process.

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?

Yes, upon the next d_revalidate, and it also would affect signal
permission checking and any other permission check against that task.

Or just use a task flag to disable checking on the module internal accesses.

I could do that too.

Unless there is some benefit to setting a ->fssid and checking against
it (e.g. safeguarding the module against unintentional internal access),
I think the task flag approach is preferable.

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?

Zero aka SECSID_NULL is unset. But a task flag may be sufficient here.

--
Stephen Smalley
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Security issues with local filesystem caching
    ... I think the task flag approach is preferable. ... Is it possible to have an SID that isn't audited? ... How do I come up with a security label for the module to use? ... include the fssid's context if that was the basis of the check. ...
    (Linux-Kernel)
  • RE: ADMT - SID History Issues, Cannot access resources in old doma
    ... permission to use this network resource. ... we need to re-ACL the resources. ... we are able to use Security Translation Wizard with a SID ... Create a SID mapping file. ...
    (microsoft.public.windows.server.migration)
  • RE: Sever migration with ADMT2
    ... Domain A listed in the shares permission. ... This is because of SID history and the fact that you performed an ADD when ... Microsoft Online Partner Support ... able to update your profile and access the the partner newsgroups. ...
    (microsoft.public.windows.server.migration)
  • RE: File permissions after migration
    ... Have you granted the permission to a group instead of the user account, ... group so that they lost the permission to access the old resource. ... we are able to use Security Translation Wizard with a SID ...
    (microsoft.public.windows.server.migration)
  • Re: [RFC][PATCH 2/7] implementation of LSM hooks
    ... domain transition occurs to a different sid. ... How could I write an SELinux policy that does this? ... Shouldn't be possible since you are allocating one in the other hook, ... And calling a secondary module here isn't likely to work anyway. ...
    (Linux-Kernel)