From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: linux-sgx@vger.kernel.org, linux-security-module@vger.kernel.org
Subject: Some LSM and SGX remarks before parting of for two weeks
Date: Fri, 12 Jul 2019 05:10:55 +0300 [thread overview]
Message-ID: <20190712021055.22qijpsahsy3gpmp@linux.intel.com> (raw)
Before going to a two week vacation (sending v21 today), I'll make some
remarks on SGX and LSM's:
1. Currently all patch sets proposing LSM changes are missing a problem
statement and describe a solution to an undescribed problem.
2. When speaking of SELinux I haven't seen any draft's on how would
define a policy module with the new constructs. Does not have to
be a full policy modules but more like snippets demosntrating that
"this would work".
3. All the SELinux discussion is centered on type based policies.
Potentially one could isolate enclaves with some UBAC or RBAC
based model. That could be good first step and might not even
require LSM changes. Type based models could be introduced
post upstreaming. No deep analysis on this, but at least this
option should ruled out at minimum before striving into type
based security model.
I guess the problem statement is more or less that since with DAC you
would have to allow to use mmap() and mprotect() to change anything
to X, even to the point that you can do WX, one needs a MAC to
somehow fix this.
Was not that hard, was it? Should be refined though with some context
why SGX requires this to not so SGX-oriented audience.
Even with just DAC this could be potentially sorted out with UBAC or
RBAC based solution e.g. have an SGID for enclave "builders" and the
device itself.
Repeating myself but type based security can be always added
aftewards.
/Jarkko
next reply other threads:[~2019-07-12 2:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-12 2:10 Jarkko Sakkinen [this message]
2019-07-12 3:12 ` Some LSM and SGX remarks before parting of for two weeks James Morris
2019-07-12 5:14 ` Jarkko Sakkinen
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=20190712021055.22qijpsahsy3gpmp@linux.intel.com \
--to=jarkko.sakkinen@linux.intel.com \
--cc=linux-security-module@vger.kernel.org \
--cc=linux-sgx@vger.kernel.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).