On 10/12/2018 04:31 AM, Jordan Glover wrote:
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Friday, October 12, 2018 3:19 AM, John Johansen
> wrote:
>>
>> It isn't perfect but it manages consistency across distros as best as
>&g
On 10/12/2018 04:31 AM, Jordan Glover wrote:
> ‐‐‐ Original Message ‐‐‐
> On Friday, October 12, 2018 2:26 AM, John Johansen
> wrote:
>
>> On 10/11/2018 04:53 PM, Jordan Glover wrote:
>>
>>> ‐‐‐ Original Message ‐‐‐
>>> On Friday,
On 10/11/2018 05:11 PM, Jordan Glover wrote:
> ‐‐‐ Original Message ‐‐‐
> On Friday, October 12, 2018 1:48 AM, John Johansen
> wrote:
>
>> On 10/11/2018 04:09 PM, Kees Cook wrote:
>>
>>> On Thu, Oct 11, 2018 at 3:58 PM, Jordan Glover
>>> golden
On 10/11/2018 04:53 PM, Jordan Glover wrote:
> ‐‐‐ Original Message ‐‐‐
> On Friday, October 12, 2018 1:09 AM, Kees Cook wrote:
>
>> We've had things sort of like this proposed, but if you can convince
>> James and others, I'm all for it. I think the standing objection from
>> James and J
On 10/11/2018 04:09 PM, Kees Cook wrote:
> On Thu, Oct 11, 2018 at 3:58 PM, Jordan Glover
> wrote:
>> On Thursday, October 11, 2018 7:57 PM, Kees Cook
>> wrote:
>>> To switch to SELinux at boot time with
>>> "CONFIG_LSM=yama,loadpin,integrity,apparmor", the old way continues to
>>> w
t;>>>> On Wed, 3 Oct 2018, Kees Cook wrote:
>>>>>
>>>>>> On Wed, Oct 3, 2018 at 11:17 AM, James Morris wrote:
>>>>>>> On Tue, 2 Oct 2018, John Johansen wrote:
>>>>>>>> To me a list like
>>>>>>>> ls
;>>>> On Wed, Oct 3, 2018 at 11:17 AM, James Morris wrote:
>>>>>> On Tue, 2 Oct 2018, John Johansen wrote:
>>>>>>> To me a list like
>>>>>>> lsm.enable=X,Y,Z
>>>>>>
>>>>>> What about even simp
On 10/03/2018 01:36 PM, Kees Cook wrote:
> On Wed, Oct 3, 2018 at 1:10 PM, Kees Cook wrote:
>> On Wed, Oct 3, 2018 at 11:28 AM, James Morris wrote:
>>> On Wed, 3 Oct 2018, Kees Cook wrote:
>>>
>>>> On Wed, Oct 3, 2018 at 11:17 AM, James Morris wrote:
On 10/03/2018 10:26 AM, Kees Cook wrote:
> On Wed, Oct 3, 2018 at 6:39 AM, Stephen Smalley wrote:
>> On 10/02/2018 07:54 PM, Kees Cook wrote:
>>>
>>> On Tue, Oct 2, 2018 at 4:46 PM, John Johansen
>>> wrote:
>>>>
>>>> On 10/02/201
On 10/02/2018 05:12 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 5:05 PM, John Johansen
> wrote:
>> On 10/02/2018 04:54 PM, Kees Cook wrote:
>>> That's not how I have it currently. It's a comma-separated a string,
>>> including the reserv
On 10/02/2018 04:54 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 4:46 PM, John Johansen
> wrote:
>> On 10/02/2018 04:06 PM, Kees Cook wrote:
>>> I think the current proposal (in the other thread) is likely the
>>> sanest approach:
>>>
>>> - Drop CO
On 10/02/2018 04:06 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 3:06 PM, James Morris wrote:
>> On Tue, 2 Oct 2018, Kees Cook wrote:
>>
>>> On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
>>> wrote:
>>>> Under the current scheme
>>>&g
On 10/02/2018 03:06 PM, James Morris wrote:
> On Tue, 2 Oct 2018, Kees Cook wrote:
>
>> On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
>> wrote:
>>> Under the current scheme
>>>
>>> lsm.enabled=selinux
>>>
>>> could actually mean se
On 10/02/2018 01:29 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 12:47 PM, John Johansen
> wrote:
>> On 10/02/2018 12:17 PM, Kees Cook wrote:
>>> I could define CONFIG_LSM_ENABLE as being "additive" to
>>> SECURITY_APPARMOR_BOOTPARAM_VALUE and
>>>
On 10/02/2018 12:17 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
> wrote:
>> Under the current scheme
>>
>> lsm.enabled=selinux
>>
>> could actually mean selinux,yama,loadpin,something_else are
>> enabled. If we extend
On 10/02/2018 09:54 AM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 9:33 AM, Jordan Glover
> wrote:
>> It's always documented as: "selinux=1 security=selinux" so security= should
>> still do the job and selinux=1 become no-op, no?
>
> The v3 patch set worked this way, yes. (The per-LSM enable defau
On 10/01/2018 04:38 PM, Kees Cook wrote:
> On Mon, Oct 1, 2018 at 4:30 PM, Kees Cook wrote:
>> If we keep it, "apparmor=0 lsm_enable=apparmor" would mean it's
>> enabled. Is that okay?
>
> Actually, what the v3 series does right now is leaves AppArmor and
> SELinux alone -- whatever they configur
On 10/01/2018 04:30 PM, Kees Cook wrote:
> On Mon, Oct 1, 2018 at 3:48 PM, John Johansen
> wrote:
>> On 10/01/2018 03:27 PM, Kees Cook wrote:
>>> On Mon, Oct 1, 2018 at 2:46 PM, John Johansen
>>> wrote:
>>>> On 09/24/2018 05:18 PM, Kees Cook wrote:
>
On 10/01/2018 03:29 PM, Kees Cook wrote:
> On Mon, Oct 1, 2018 at 3:20 PM, John Johansen
> wrote:
>> On 10/01/2018 02:56 PM, Kees Cook wrote:
>>> On Mon, Oct 1, 2018 at 2:47 PM, James Morris wrote:
>>>> On Mon, 24 Sep 2018, Kees Cook wrote:
>>>>
>
On 10/01/2018 03:27 PM, Kees Cook wrote:
> On Mon, Oct 1, 2018 at 2:46 PM, John Johansen
> wrote:
>> On 09/24/2018 05:18 PM, Kees Cook wrote:
>>> This introduces the "lsm.enable=..." and "lsm.disable=..." boot parameters
>>> which each can c
On 10/01/2018 02:56 PM, Kees Cook wrote:
> On Mon, Oct 1, 2018 at 2:47 PM, James Morris wrote:
>> On Mon, 24 Sep 2018, Kees Cook wrote:
>>
>>> In preparation for lifting the "is this LSM enabled?" logic out of the
>>> individual LSMs, pass in any special enabled state tracking (as needed
>>> for S
re.
>
> Signed-off-by: Kees Cook
Reviewed-by: John Johansen
> ---
> security/security.c | 17 -
> 1 file changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/security/security.c b/security/security.c
> index 456a3f73bc36..e325fcc41f00 10064
On 09/24/2018 05:18 PM, Kees Cook wrote:
> This introduces the "lsm.enable=..." and "lsm.disable=..." boot parameters
> which each can contain a comma-separated list of LSMs to enable or
> disable, respectively. The string "all" matches all LSMs.
>
> This has very similar functionality to the exis
On 09/24/2018 05:18 PM, Kees Cook wrote:
> To provide a set of default-enabled LSMs at boot, this introduces the
> new CONFIG_LSM_ENABLE. A value of "all" means all builtin LSMs are
> enabled by default. Any unlisted LSMs will be implicitly disabled
> (excepting those with LSM-specific CONFIGs for
parameter) because its use will be
> expanded on in the following patches to provide more explicit enabling.
>
> Signed-off-by: Kees Cook
Reviewed-by: John Johansen
> ---
> security/security.c | 69 ++---
> 1 file changed, 65 inser
unless they specified an external "enable"
> variable.
>
> Signed-off-by: Kees Cook
Reviewed-by: John Johansen
> ---
> include/linux/lsm_hooks.h | 1 -
> security/apparmor/lsm.c| 6 ---
> security/security.c| 84 --
handling any future cases where "enabled" is exposed via sysctl which
> has no "bool" type.
>
> Signed-off-by: Kees Cook
Reviewed-by: John Johansen
> ---
> include/linux/lsm_hooks.h | 1 +
> security/apparmor/lsm.c | 5 +++--
> security/selinux/hoo
; its enforcement).
>
> Signed-off-by: Kees Cook
Reviewed-by: John Johansen
> ---
> security/loadpin/Kconfig | 4 ++--
> security/loadpin/loadpin.c | 21 +++--
> 2 files changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/security/loadpin/Kco
: Kees Cook
I know its already being done, but I don't like splitting the init
order
Reviewed-by: John Johansen
> ---
> security/security.c | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/security/security.c b/security/security.c
> in
sharing world.
>
> Signed-off-by: Kees Cook
Reviewed-by: John Johansen
> ---
> include/linux/lsm_hooks.h | 3 +++
> security/apparmor/lsm.c| 1 +
> security/selinux/hooks.c | 1 +
> security/smack/smack_lsm.c | 1 +
> security/tomoyo/tomoyo.c | 1 +
> 5 files
On 09/24/2018 05:18 PM, Kees Cook wrote:
> LSM initialization failures have traditionally been ignored. We should
> at least WARN when something goes wrong.
>
> Signed-off-by: Kees Cook
about time
Reviewed-by: John Johansen
> ---
> security/security.c | 4 +++-
&g
On 09/24/2018 05:18 PM, Kees Cook wrote:
> Booting with "lsm.debug" will report future details on how LSM ordering
> decisions are being made.
>
> Signed-off-by: Kees Cook
Reviewed-by: John Johansen
> ---
> .../admin-guide/kernel-parameters.txt |
On 09/24/2018 05:18 PM, Kees Cook wrote:
> In preparation for making LSM selections outside of the LSMs, include
> the name of LSMs in struct lsm_info.
>
> Cc: James Morris
> Signed-off-by: Kees Cook
I'll leave this one until after the changes you have already discussed with
Tetsuo around, END
On 09/24/2018 05:18 PM, Kees Cook wrote:
> Instead of using argument-based initializers, switch to defining the
> contents of struct lsm_info on a per-LSM basis. This also drops
> the final use of the now inaccurate "initcall" naming.
>
> Cc: John Johansen
> Cc:
On 09/24/2018 05:18 PM, Kees Cook wrote:
> Since the struct lsm_info table is not an initcall, we can just move it
> into INIT_DATA like all the other tables.
>
> Cc: linux-a...@vger.kernel.org
> Signed-off-by: Kees Cook
Reviewed-by: John Johansen
> ---
> arch/arc
;Serge E. Hallyn"
> Cc: Ard Biesheuvel
> Cc: Paul Moore
> Cc: linux-security-mod...@vger.kernel.org
> Signed-off-by: Kees Cook
Reviewed-by: John Johansen
> ---
> include/linux/init.h | 2 --
> include/linux/lsm_hooks.h | 12
> include/linux/
Cc: "Serge E. Hallyn"
> Cc: Abderrahmane Benbachir
> Cc: Steven Rostedt (VMware)
> Cc: linux-security-mod...@vger.kernel.org
> Signed-off-by: Kees Cook
Reviewed-by: John Johansen
though I do think it would be a good idea to add a new set
of trace points, but that can come
c: linux-a...@vger.kernel.org
> Cc: linux-security-mod...@vger.kernel.org
> Signed-off-by: Kees Cook
Reviewed-by: John Johansen
> ---
> include/asm-generic/vmlinux.lds.h | 10 +-
> include/linux/init.h | 4 ++--
> security/security.c | 4 +
On 09/24/2018 05:18 PM, Kees Cook wrote:
> Avoid copy/paste by defining SECURITY_INIT in terms of SECURITY_INITCALL.
>
> Cc: Arnd Bergmann
> Cc: linux-a...@vger.kernel.org
> Signed-off-by: Kees Cook
Reviewed-by: John Johansen
> ---
> include/asm-gener
ed-off-by: Kees Cook
> Reviewed-by: Casey Schaufler
Reviewed-by: John Johansen
> ---
> security/security.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/security/security.c b/security/security.c
> index 736e78da1ab9..4cbcf244a965 100644
> --- a/
On 09/29/2018 03:48 AM, Tetsuo Handa wrote:
> On 2018/09/29 5:01, Kees Cook wrote:
>> On Fri, Sep 28, 2018 at 8:55 AM, Casey Schaufler
>> wrote:
>>> On 9/24/2018 5:18 PM, Kees Cook wrote:
v3:
- add CONFIG_LSM_ENABLE and refactor resulting logic
>>>
>>> Kees, you can add my
>>>
>>>
On 05/13/2017 04:51 AM, Kees Cook wrote:
> Adjusts for ReST markup and moves under LSM admin guide.
>
> Cc: John Johansen
> Signed-off-by: Kees Cook
Acked-by: John Johansen
> ---
> .../apparmor.txt => admin-guide/LSM/apparmor.rst} | 36
> ++
>
42 matches
Mail list logo
