[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <575cbfd2-e05b-83a9-faed-d07011c8bd5e@schaufler-ca.com>
Date: Thu, 27 Oct 2016 17:05:06 -0700
From: Casey Schaufler <casey@...aufler-ca.com>
To: James Morris <jmorris@...ei.org>
Cc: LSM <linux-security-module@...r.kernel.org>,
John Johansen <john.johansen@...onical.com>,
Paul Moore <paul@...l-moore.com>,
Kees Cook <keescook@...omium.org>,
Stephen Smalley <sds@...ho.nsa.gov>,
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
LKLM <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v6 0/3] LSM: security module information improvements
On 10/27/2016 3:32 PM, James Morris wrote:
> On Wed, 26 Oct 2016, Casey Schaufler wrote:
>
>> Create interfaces that make it possible to deal with process
>> attributes in the face of multiple "major" security modules.
> We don't have support for multiple major modules currently (perhaps ever),
> so I'm not merging infrastructure which is only useful for them.
The 2/3 patch provides for disambiguation of "current"
whether you have multiple modules or just one. In effect
it corrects an error made in both Smack and AppArmor to
reuse the attribute interface names from SELinux. There
was substantial discussion on the LSM list about how best
to address this. I had originally suggested new names in
the attr directory, but the subdirectory approach was
greatly preferred by the populous.
The 3/3 patch is forward looking, I'll admit. Userspace
can start getting ready for the combined format in
advance of multiple major modules. When complete module
stacking patches are available I don't want to be addressing
"no userspace is set up to handle that" if at all possible.
I don't want to be Chicken or Egged to death. The attr/context
would be the ideal thing for the id command to report, as
the format would always be the same and identify the module(s).
>
>> Patch 1/3 adds /sys/kernel/security/lsm, which provides
>> a list of the active security modules on the system.
>>
>> $ cat /sys/kernel/security/lsm
>> capability,yama,loadpin,smack
> This may make sense on its own. Has anyone requested this, or is likely
> to adopt it into a distro?
As John mentioned, Ubuntu would like this. I expect to use
it in the Smack userspace, hence Tizen.
Powered by blists - more mailing lists