From: greg@kroah.com (Greg KH)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Is there mailist about LSM
Date: Wed, 30 May 2018 20:35:28 +0200 [thread overview]
Message-ID: <20180530183528.GA20534@kroah.com> (raw)
In-Reply-To: <1184751527704026@web33g.yandex.ru>
On Wed, May 30, 2018 at 09:13:46PM +0300, Ozgur Kara wrote:
>
>
> 30.05.2018, 21:08, "valdis.kletnieks at vt.edu" <valdis.kletnieks@vt.edu>:
> > On Wed, 30 May 2018 10:37:25 -0700, you said:
> >
> >> ?First, theoretical, I suppose: what were the reasons to effectively disable dynamic loading of LSM ?
> >
> > Because that implies the system was up without the LSM loaded - at which point
> > somebody can have tampered with whatever labelling the LSM uses. So we
> > insist that the LSM be brought online very early during the boot process, to make
> > sure that the LSM has a chance to stop any unauthorized relabeling.
> >
> >> ?Second, is there a way for two or more LSMs to co-exist? After inspecting
> >> ?security_module_enable() and register_security(), it doesn't seem possible,
> >> ?however yama does attempt to load itself? Am I missing something?
> >
> > There's some support for one "large" LSM and a "trivial" one like yama.
> > There's very real and nasty interactions if you try to run (for instance)
> > SELinux and AppArmor at the same time. The composition of multiple
> > MAC systems is fraught with danger (go back and look at how long it took
> > us to get file capabilities to work right...)
>
> SElinux and AppArmor are completely disappointing.
> Really.
Fair enough, you are free to create a competing LSM. This is the very
reason that the interface was made in the first place. Because no one
can decide what the "best" security model is for everyone else.
Thanks for proving the design decision was a correct one :)
greg k-h
next prev parent reply other threads:[~2018-05-30 18:35 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-30 17:16 Is there mailist about LSM Alexander Ivanov
2018-05-30 17:25 ` valdis.kletnieks at vt.edu
2018-05-30 17:35 ` Greg KH
2018-05-30 17:59 ` Ozgur Kara
2018-05-30 18:02 ` valdis.kletnieks at vt.edu
2018-05-30 18:09 ` Ozgur Kara
2018-05-30 18:23 ` valdis.kletnieks at vt.edu
2018-05-30 17:37 ` Alexander Ivanov
2018-05-30 18:05 ` valdis.kletnieks at vt.edu
2018-05-30 18:13 ` Alexander Ivanov
2018-05-30 18:26 ` valdis.kletnieks at vt.edu
2018-05-30 22:10 ` Alexander Ivanov
2018-05-31 5:22 ` Ozgur Kara
2018-05-31 6:00 ` Alexander Ivanov
2018-05-31 21:11 ` Thibaut Sautereau
2018-05-31 22:33 ` Alexander Ivanov
2018-05-30 18:13 ` Ozgur Kara
2018-05-30 18:35 ` Greg KH [this message]
2018-05-30 18:12 ` Greg KH
2018-05-30 18:18 ` Alexander Ivanov
2018-05-30 17:54 ` Ozgur Kara
2018-05-30 18:01 ` Alexander Ivanov
2018-05-30 18:05 ` Ozgur Kara
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=20180530183528.GA20534@kroah.com \
--to=greg@kroah.com \
--cc=kernelnewbies@lists.kernelnewbies.org \
/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).