lkml.org 
[lkml]   [2017]   [Apr]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] selinux: add selinux_is_enforced() function
2017-04-12 16:35 GMT+02:00 Stephen Smalley <sds@tycho.nsa.gov>:
> How are you using this SELinux information in the kernel and/or in
> userspace? What's the purpose of it? What are you comparing it
> against? Why do you care if it changes?

Enforcement status and policy version are compared to their previously
stored value. If they differ, then it means we need to call a userland
helper from Lustre client kernelspace to read the currently loaded
policy (reading it will let us know if the Lustre client node is
conforming to the Lustre-wide security policy).
As calling the userland helper is costly, we do it only when it is
necessary by retrieving some SELinux key information directly from
kernelspace.

> Note btw that the notion of a policy name/type and the policy file path
> is purely a userspace construct and shouldn't be embedded in your
> kernel code. Android for example doesn't follow that convention at
> all; their SELinux policy file is simply /sepolicy. On modern kernels,
> you can always read the currently loaded policy from the kernel itself
> via /sys/fs/selinux/policy (formerly just /selinux/policy).

As I understand it, a userspace program can directly read the policy
info exposed by the kernel by reading this file. But how about reading
it from kernelspace?

\
 
 \ /
  Last update: 2017-04-12 17:13    [W:0.042 / U:41.108 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site