linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Igor Zhbanov <izh1979@gmail.com>
To: THOBY Simon <Simon.THOBY@viveris.fr>
Cc: Igor Zhbanov <i.zhbanov@omp.ru>,
	linux-integrity <linux-integrity@vger.kernel.org>,
	linux-security-module <linux-security-module@vger.kernel.org>,
	Mimi Zohar <zohar@linux.ibm.com>
Subject: Re: [PATCH 1/1] NAX LSM: Add initial support support
Date: Sat, 14 Aug 2021 16:39:43 +0300	[thread overview]
Message-ID: <CAEUiM9N-ELgr2bPvn=5P4NR8wQAKwkZ6tGFZAE8wjH16sWPZVg@mail.gmail.com> (raw)
In-Reply-To: <a41a0116-8d05-3aea-d979-090cdbb1d52f@viveris.fr>

Hi Simon,

пт, 13 авг. 2021 г. в 11:08, THOBY Simon <Simon.THOBY@viveris.fr>:
> For the matter of have a kernel commandline being the result of concatenations from multiple
> sources, I think that if any attacker is able to alter part of the command line, they can
> already write 'lsm=' to it and completely disable NAX, thus I'm not sure 'nax_locked' should
> impact other setup_* functions.
>
> I believe keeping the nax_locked parameter, but not checking for the 'locked' status in the other setup_*
> functions should be enought, as sysctls writes will still be protected by the 'locked' variable.

I thought again about it. Currently it is possible to set parameters
value in Kconfig, including "locked".
So, if one needed some static configuration, that cannot be altered by
any means, they can set
the desired values at compilation time in Kconfig and it will be
impossible to change it, nor by sysctl,
nor by command-line.

But if I remove that (!locked) check, then the command-line options
would alway be able to override
the compile-time configuration, including unlocking the locked state.

Thank you.

  reply	other threads:[~2021-08-14 13:39 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-07  1:03 [PATCH 1/1] NAX LSM: Add initial support support Igor Zhbanov
2021-07-28 10:19 ` THOBY Simon
2021-08-10  4:52   ` J Freyensee
2021-08-12 14:47     ` THOBY Simon
2021-08-12 16:43   ` Igor Zhbanov
2021-08-13  8:08     ` THOBY Simon
2021-08-14 13:39       ` Igor Zhbanov [this message]
2021-08-16  7:39         ` THOBY Simon
2021-08-12 20:24   ` Igor Zhbanov
2021-08-13  7:47     ` THOBY Simon
2021-08-13  8:05       ` Igor Zhbanov
2021-08-13  8:23         ` THOBY Simon
2021-08-13 20:10   ` Igor Zhbanov
2021-08-16  7:31     ` THOBY Simon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAEUiM9N-ELgr2bPvn=5P4NR8wQAKwkZ6tGFZAE8wjH16sWPZVg@mail.gmail.com' \
    --to=izh1979@gmail.com \
    --cc=Simon.THOBY@viveris.fr \
    --cc=i.zhbanov@omp.ru \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).