* Re: [RFC PATCH v2 2/5] x86/sgx: Require userspace to define enclave pages' protection bits
From: Sean Christopherson @ 2019-06-12 14:34 UTC (permalink / raw)
To: Andy Lutomirski, q
Cc: Xing, Cedric, Andy Lutomirski, Jarkko Sakkinen, Stephen Smalley,
James Morris, Serge E . Hallyn, LSM List, Paul Moore, Eric Paris,
selinux@vger.kernel.org, Jethro Beekman, Hansen, Dave,
Thomas Gleixner, Linus Torvalds, LKML, X86 ML,
linux-sgx@vger.kernel.org, Andrew Morton, nhorman@redhat.com,
npmccallum@redhat.com, Ayoun, Serge, Katz-zamir, Shay,
Huang, Haitao, Andy Shevchenko, Svahn, Kai, Borislav Petkov,
Josh Triplett, Huang, Kai, David Rientjes, Roberts, William C,
Tricca, Philip B
In-Reply-To: <331B31BF-9892-4FB3-9265-3E37412F80F4@amacapital.net>
On Tue, Jun 11, 2019 at 05:09:28PM -0700, Andy Lutomirski wrote:
>
> On Jun 10, 2019, at 3:28 PM, Xing, Cedric <cedric.xing@intel.com> wrote:
>
> >> From: Andy Lutomirski [mailto:luto@kernel.org]
> >> Sent: Monday, June 10, 2019 12:15 PM
> >> This seems like an odd workflow. Shouldn't the #PF return back to
> >> untrusted userspace so that the untrusted user code can make its own
> >> decision as to whether it wants to EAUG a page there as opposed to, say,
> >> killing the enclave or waiting to keep resource usage under control?
> >
> > This may seem odd to some at the first glance. But if you can think of how
> > static heap (pre-allocated by EADD before EINIT) works, the load parses the
> > "metadata" coming with the enclave to decide the address/size of the heap,
> > EADDs it, and calls it done. In the case of "dynamic" heap (allocated
> > dynamically by EAUG after EINIT), the same thing applies - the loader
> > determines the range of the heap, tells the SGX module about it, and calls
> > it done. Everything else is the between the enclave and the SGX module.
> >
> > In practice, untrusted code usually doesn't know much about enclaves, just
> > like it doesn't know much about the shared objects loaded into its address
> > space either. Without the necessary knowledge, untrusted code usually just
> > does what it is told (via o-calls, or return value from e-calls), without
> > judging that's right or wrong.
> >
> > When it comes to #PF like what I described, of course a signal could be
> > sent to the untrusted code but what would it do then? Usually it'd just
> > come back asking for a page at the fault address. So we figured it'd be
> > more efficient to just have the kernel EAUG at #PF.
> >
> > Please don't get me wrong though, as I'm not dictating what the s/w flow
> > shall be. It's just going to be a choice offered to user mode. And that
> > choice was planned to be offered via mprotect() - i.e. a writable vma
> > causes kernel to EAUG while a non-writable vma will result in a signal
> > (then the user mode could decide whether to EAUG). The key point is
> > flexibility - as we want to allow all reasonable s/w flows instead of
> > dictating one over others. We had similar discussions on vDSO API before.
> > And I think you accepted my approach because of its flexibility. Am I
> > right?
>
> As long as user code can turn this off, I have no real objection. But it
> might make sense to have it be more explicit — have an ioctl set up a range
> as “EAUG-on-demand”.
This was part of the motivation behind changing SGX_IOC_ENCLAVE_ADD_PAGE
to SGX_IOC_ENCLAVE_ADD_REGION and adding a @flags parameter. E.g. adding
support for "EAUG-on-demand" regions would just be a new flag.
> But this is all currently irrelevant. We can argue about it when the patches
> show up. :)
^ permalink raw reply
* Re: [PATCH v3 18/33] docs: netlabel: convert docs to ReST and rename to *.rst
From: Paul Moore @ 2019-06-12 14:48 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, netdev, linux-security-module
In-Reply-To: <6094c48c791a28a0d28f9854e8f198625cc524f4.1560045490.git.mchehab+samsung@kernel.org>
On Sat, Jun 8, 2019 at 10:27 PM Mauro Carvalho Chehab
<mchehab+samsung@kernel.org> wrote:
>
> Convert netlabel documentation to ReST.
>
> This was trivial: just add proper title markups.
>
> At its new index.rst, let's add a :orphan: while this is not linked to
> the main index.rst file, in order to avoid build warnings.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> .../{cipso_ipv4.txt => cipso_ipv4.rst} | 19 +++++++++++------
> Documentation/netlabel/draft_ietf.rst | 5 +++++
> Documentation/netlabel/index.rst | 21 +++++++++++++++++++
> .../{introduction.txt => introduction.rst} | 16 +++++++++-----
> .../{lsm_interface.txt => lsm_interface.rst} | 16 +++++++++-----
> 5 files changed, 61 insertions(+), 16 deletions(-)
> rename Documentation/netlabel/{cipso_ipv4.txt => cipso_ipv4.rst} (87%)
> create mode 100644 Documentation/netlabel/draft_ietf.rst
> create mode 100644 Documentation/netlabel/index.rst
> rename Documentation/netlabel/{introduction.txt => introduction.rst} (91%)
> rename Documentation/netlabel/{lsm_interface.txt => lsm_interface.rst} (88%)
I'm fairly confident I've already acked this at least once, but here
it is again:
Acked-by: Paul Moore <paul@paul-moore.com>
> diff --git a/Documentation/netlabel/cipso_ipv4.txt b/Documentation/netlabel/cipso_ipv4.rst
> similarity index 87%
> rename from Documentation/netlabel/cipso_ipv4.txt
> rename to Documentation/netlabel/cipso_ipv4.rst
> index a6075481fd60..cbd3f3231221 100644
> --- a/Documentation/netlabel/cipso_ipv4.txt
> +++ b/Documentation/netlabel/cipso_ipv4.rst
> @@ -1,10 +1,13 @@
> +===================================
> NetLabel CIPSO/IPv4 Protocol Engine
> -==============================================================================
> +===================================
> +
> Paul Moore, paul.moore@hp.com
>
> May 17, 2006
>
> - * Overview
> +Overview
> +========
>
> The NetLabel CIPSO/IPv4 protocol engine is based on the IETF Commercial
> IP Security Option (CIPSO) draft from July 16, 1992. A copy of this
> @@ -13,7 +16,8 @@ draft can be found in this directory
> it to an RFC standard it has become a de-facto standard for labeled
> networking and is used in many trusted operating systems.
>
> - * Outbound Packet Processing
> +Outbound Packet Processing
> +==========================
>
> The CIPSO/IPv4 protocol engine applies the CIPSO IP option to packets by
> adding the CIPSO label to the socket. This causes all packets leaving the
> @@ -24,7 +28,8 @@ label by using the NetLabel security module API; if the NetLabel "domain" is
> configured to use CIPSO for packet labeling then a CIPSO IP option will be
> generated and attached to the socket.
>
> - * Inbound Packet Processing
> +Inbound Packet Processing
> +=========================
>
> The CIPSO/IPv4 protocol engine validates every CIPSO IP option it finds at the
> IP layer without any special handling required by the LSM. However, in order
> @@ -33,7 +38,8 @@ NetLabel security module API to extract the security attributes of the packet.
> This is typically done at the socket layer using the 'socket_sock_rcv_skb()'
> LSM hook.
>
> - * Label Translation
> +Label Translation
> +=================
>
> The CIPSO/IPv4 protocol engine contains a mechanism to translate CIPSO security
> attributes such as sensitivity level and category to values which are
> @@ -42,7 +48,8 @@ Domain Of Interpretation (DOI) definition and are configured through the
> NetLabel user space communication layer. Each DOI definition can have a
> different security attribute mapping table.
>
> - * Label Translation Cache
> +Label Translation Cache
> +=======================
>
> The NetLabel system provides a framework for caching security attribute
> mappings from the network labels to the corresponding LSM identifiers. The
> diff --git a/Documentation/netlabel/draft_ietf.rst b/Documentation/netlabel/draft_ietf.rst
> new file mode 100644
> index 000000000000..5ed39ab8234b
> --- /dev/null
> +++ b/Documentation/netlabel/draft_ietf.rst
> @@ -0,0 +1,5 @@
> +Draft IETF CIPSO IP Security
> +----------------------------
> +
> + .. include:: draft-ietf-cipso-ipsecurity-01.txt
> + :literal:
> diff --git a/Documentation/netlabel/index.rst b/Documentation/netlabel/index.rst
> new file mode 100644
> index 000000000000..47f1e0e5acd1
> --- /dev/null
> +++ b/Documentation/netlabel/index.rst
> @@ -0,0 +1,21 @@
> +:orphan:
> +
> +========
> +NetLabel
> +========
> +
> +.. toctree::
> + :maxdepth: 1
> +
> + introduction
> + cipso_ipv4
> + lsm_interface
> +
> + draft_ietf
> +
> +.. only:: subproject and html
> +
> + Indices
> + =======
> +
> + * :ref:`genindex`
> diff --git a/Documentation/netlabel/introduction.txt b/Documentation/netlabel/introduction.rst
> similarity index 91%
> rename from Documentation/netlabel/introduction.txt
> rename to Documentation/netlabel/introduction.rst
> index 3caf77bcff0f..9333bbb0adc1 100644
> --- a/Documentation/netlabel/introduction.txt
> +++ b/Documentation/netlabel/introduction.rst
> @@ -1,10 +1,13 @@
> +=====================
> NetLabel Introduction
> -==============================================================================
> +=====================
> +
> Paul Moore, paul.moore@hp.com
>
> August 2, 2006
>
> - * Overview
> +Overview
> +========
>
> NetLabel is a mechanism which can be used by kernel security modules to attach
> security attributes to outgoing network packets generated from user space
> @@ -12,7 +15,8 @@ applications and read security attributes from incoming network packets. It
> is composed of three main components, the protocol engines, the communication
> layer, and the kernel security module API.
>
> - * Protocol Engines
> +Protocol Engines
> +================
>
> The protocol engines are responsible for both applying and retrieving the
> network packet's security attributes. If any translation between the network
> @@ -24,7 +28,8 @@ the NetLabel kernel security module API described below.
> Detailed information about each NetLabel protocol engine can be found in this
> directory.
>
> - * Communication Layer
> +Communication Layer
> +===================
>
> The communication layer exists to allow NetLabel configuration and monitoring
> from user space. The NetLabel communication layer uses a message based
> @@ -33,7 +38,8 @@ formatting of these NetLabel messages as well as the Generic NETLINK family
> names can be found in the 'net/netlabel/' directory as comments in the
> header files as well as in 'include/net/netlabel.h'.
>
> - * Security Module API
> +Security Module API
> +===================
>
> The purpose of the NetLabel security module API is to provide a protocol
> independent interface to the underlying NetLabel protocol engines. In addition
> diff --git a/Documentation/netlabel/lsm_interface.txt b/Documentation/netlabel/lsm_interface.rst
> similarity index 88%
> rename from Documentation/netlabel/lsm_interface.txt
> rename to Documentation/netlabel/lsm_interface.rst
> index 638c74f7de7f..026fc267f798 100644
> --- a/Documentation/netlabel/lsm_interface.txt
> +++ b/Documentation/netlabel/lsm_interface.rst
> @@ -1,10 +1,13 @@
> +========================================
> NetLabel Linux Security Module Interface
> -==============================================================================
> +========================================
> +
> Paul Moore, paul.moore@hp.com
>
> May 17, 2006
>
> - * Overview
> +Overview
> +========
>
> NetLabel is a mechanism which can set and retrieve security attributes from
> network packets. It is intended to be used by LSM developers who want to make
> @@ -12,7 +15,8 @@ use of a common code base for several different packet labeling protocols.
> The NetLabel security module API is defined in 'include/net/netlabel.h' but a
> brief overview is given below.
>
> - * NetLabel Security Attributes
> +NetLabel Security Attributes
> +============================
>
> Since NetLabel supports multiple different packet labeling protocols and LSMs
> it uses the concept of security attributes to refer to the packet's security
> @@ -24,7 +28,8 @@ configuration. It is up to the LSM developer to translate the NetLabel
> security attributes into whatever security identifiers are in use for their
> particular LSM.
>
> - * NetLabel LSM Protocol Operations
> +NetLabel LSM Protocol Operations
> +================================
>
> These are the functions which allow the LSM developer to manipulate the labels
> on outgoing packets as well as read the labels on incoming packets. Functions
> @@ -32,7 +37,8 @@ exist to operate both on sockets as well as the sk_buffs directly. These high
> level functions are translated into low level protocol operations based on how
> the administrator has configured the NetLabel subsystem.
>
> - * NetLabel Label Mapping Cache Operations
> +NetLabel Label Mapping Cache Operations
> +=======================================
>
> Depending on the exact configuration, translation between the network packet
> label and the internal LSM security identifier can be time consuming. The
> --
> 2.21.0
>
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH v2 1/2] LSM: switch to blocking policy update notifiers
From: Paul Moore @ 2019-06-12 15:15 UTC (permalink / raw)
To: Mimi Zohar
Cc: Janne Karhunen, Stephen Smalley, linux-integrity,
linux-security-module
In-Reply-To: <1560346093.4578.18.camel@linux.ibm.com>
On Wed, Jun 12, 2019 at 9:28 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> Hi Paul,
/me waves
> On Wed, 2019-06-12 at 10:44 +0300, Janne Karhunen wrote:
> > Atomic policy updaters are not very useful as they cannot
> > usually perform the policy updates on their own. Since it
> > seems that there is no strict need for the atomicity,
> > switch to the blocking variant. While doing so, rename
> > the functions accordingly.
> >
> > Changelog v2
> > - Rebase to 'next-queued-testing'
> >
> > Signed-off-by: Janne Karhunen <janne.karhunen@gmail.com>
> > Acked-by: Paul Moore <paul@paul-moore.com>
>
> The patches need to be upstreamed together. Do you have any problems
> with my upstreaming them via linux-integrity?
Nope, I've been operating under the assumption that you would be
taking both patches via the linux-integrity tree.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH v3 0/2] ima/evm fixes for v5.2
From: Roberto Sassu @ 2019-06-12 16:33 UTC (permalink / raw)
To: Janne Karhunen
Cc: Mimi Zohar, dmitry.kasatkin, mjg59, linux-integrity,
linux-security-module, silviu.vlasceanu
In-Reply-To: <CAE=NcraHqzST=SZNcrSgpv5EqfyUfpCCb7iQ0Oh6uohL3yiCdw@mail.gmail.com>
On 6/12/2019 3:38 PM, Janne Karhunen wrote:
> On Wed, Jun 12, 2019 at 4:11 PM Roberto Sassu <roberto.sassu@huawei.com> wrote:
>
>>> - after initialization
>>> - deny reading|writing anything without security.ima
>>> - deny reading|writing anything invalid
>>> - allow everything else
>>>
>>> The logic is pretty handy as it even creates additional layer of
>>> security around the early initialization files as they become
>>> unreadable after use.
>>
>> What if they should be legitimately used after the HMAC key is unsealed
>> and before switching to the persistent root file system?
>
> Any examples? Log files and such are mostly 'one way' and should
> probably be whitelisted in the policy?
I checked better when the random key would be used to verify files
created during the boot. If we consider rootfs only, basically it would
be used for dracut-state.sh.
Before I was using a rule to measure digest lists in tmpfs. I had many
errors due to the fact that appraisal denied access to files in /run.
The default policy does not appraise files in tmpfs, and also for digest
lists it is not necessary (now I use: measure/appraise fsname=rootfs).
>>> Now, if we initialize the system with a random key like in your patch,
>>> this logic is to change quite drastically? It sounds to me the
>>> userland may actually break, all the userland initialization files in
>>> the existing ima configurations that do not use digsigs would become
>>> unreadable given that the random key is put in? Remember, those files
>>> can be protected via other means (most commonly signed ramdisk).
>>
>> No, the first patch is about adding the ability to verify files created
>> during each boot. For any other file, EVM returns INTEGRITY_UNKNOWN as
>> before. The second patch changes the behavior, as INTEGRITY_UNKNOWN is
>> considered as an error for the enforce-evm appraisal mode. The second
>> patch aims at making the system more secure, as no file would be
>> accessible unless it is verified.
>>
>> It is true that configurations without digsigs won't work anymore but
>> the alternative is accepting any file until the HMAC key is unsealed.
>
> That's a pretty big change for the userland IMHO. Quite a few
> configurations out there will break, including mine I believe, so I
> hope there is a solid reason asking people to change their stuff. I'm
> fine holding off all writing until it is safe to do so for now..
The goal of appraisal is to allow access only to files with a valid
signature or HMAC. With the current behavior, that cannot be guaranteed.
Unfortunately, dracut-state.sh is created very early. It could be
possible to unseal the key before, but this probably means modifying
systemd.
Roberto
--
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Jian LI, Yanli SHI
^ permalink raw reply
* Re: What do LSMs *actually* need for checks on notifications?
From: David Howells @ 2019-06-12 17:41 UTC (permalink / raw)
To: Casey Schaufler
Cc: dhowells, Stephen Smalley, Andy Lutomirski, viro, linux-usb,
linux-security-module, linux-fsdevel, linux-kernel
In-Reply-To: <9c41cd56-af21-f17d-ab54-66615802f30e@schaufler-ca.com>
Casey Schaufler <casey@schaufler-ca.com> wrote:
> > (4) The security attributes of the object on which the watch was set (uid,
> > gid, mode, labels).
>
> Smack needs this to set a watch on the named object (file, key, ...).
> I am going to say that if you can't access an object you can't watch it.
So for the things I've so far defined:
(*) Keys/keyrings require View permission, but it could be Read permission
instead - though that may get disabled if the key type does not support
KEYCTL_READ.
(*) Mount/superblock watches - I've made these require execute permission on
the specified directory. Could be read permission instead.
(*) Device events (block/usb) don't require any permissions, but currently
only deliver hardware notifications.
> I think that read access is sufficient provided that no one else can
> see what watches I've created.
You can't find out what watches exist.
> > At the moment, when post_one_notification() wants to write a notification
> > into a queue, it calls security_post_notification() to ask if it should be
> > allowed to do so. This is passed (1) and (3) above plus the notification
> > record.
>
> Is "current" (2)? Smack needs (2) for the event delivery access check.
(2) was current_cred() when watch_sb(), KEYCTL_NOTIFY, etc. was called, but
isn't necessarily current_cred() at the point post_one_notification() is
called. The latter is called at the point the event is generated and
current_cred() is the creds of whatever thread that is called in (which may be
a work_queue thread if it got deferred).
At the moment, I'm storing the creds of whoever opened the queue (ie. (1)) and
using that, but I could cache the creds of whoever created each watch
(ie. (2)) and pass that to post_one_notification() instead.
However, it should be noted that (1) is the creds of the buffer owner.
> > (e) All the points at which we walk over an object in a chain from (c) to
> > find the watch on which we can effect (d) (eg. we walk rootwards from a
> > mountpoint to find watches on a branch in the mount topology).
>
> Smack does not require anything beyond existing checks.
I'm glad to hear that, as this might be sufficiently impractical as to render
it unusable with Smack. Calling i_op->permissions() a lot would suck.
> > (y) What checks should be done on object destruction after final put and
> > what contexts need to be supplied?
>
> Classically there is no such thing as filesystem object deletion.
> By making it possible to set a watch on that you've inadvertently
> added a security relevant action to the security model. :o
That wasn't my original intention - I intended fsmount(2) to mount directly as
mount(2) does, but Al had other ideas.
Now fsmount(2) produces a file descriptor referring to a new mount object that
can be mounted into by move_mount(2) before being spliced into the mount
topology by move_mount(2). However, if the fd is closed before the last step,
close() will destroy the mount subtree attached to it (kind of quasi-unmount).
That wouldn't be a problem, except that the fd from fsmount(2) can be used
anywhere an O_PATH fd can be used - including watch_mount(2), fchdir(2), ...
Further, FMODE_NEED_UNMOUNT gets cleared if the mount is spliced in at least
once.
Okay, having tried it you don't get an unmount event (since there's no actual
unmount), but you do get an event to say that your watch got deleted (if the
directory on which the watch was placed got removed from the system).
So... does the "your watch got deleted" message need checking? In my
opinion, it shouldn't get discarded because then the watcher doesn't know
their watch went away.
David
^ permalink raw reply
* [PATCH v4 16/28] docs: netlabel: convert docs to ReST and rename to *.rst
From: Mauro Carvalho Chehab @ 2019-06-12 17:52 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Paul Moore, netdev, linux-security-module
In-Reply-To: <cover.1560361364.git.mchehab+samsung@kernel.org>
Convert netlabel documentation to ReST.
This was trivial: just add proper title markups.
At its new index.rst, let's add a :orphan: while this is not linked to
the main index.rst file, in order to avoid build warnings.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: Paul Moore <paul@paul-moore.com>
---
.../{cipso_ipv4.txt => cipso_ipv4.rst} | 19 +++++++++++------
Documentation/netlabel/draft_ietf.rst | 5 +++++
Documentation/netlabel/index.rst | 21 +++++++++++++++++++
.../{introduction.txt => introduction.rst} | 16 +++++++++-----
.../{lsm_interface.txt => lsm_interface.rst} | 16 +++++++++-----
5 files changed, 61 insertions(+), 16 deletions(-)
rename Documentation/netlabel/{cipso_ipv4.txt => cipso_ipv4.rst} (87%)
create mode 100644 Documentation/netlabel/draft_ietf.rst
create mode 100644 Documentation/netlabel/index.rst
rename Documentation/netlabel/{introduction.txt => introduction.rst} (91%)
rename Documentation/netlabel/{lsm_interface.txt => lsm_interface.rst} (88%)
diff --git a/Documentation/netlabel/cipso_ipv4.txt b/Documentation/netlabel/cipso_ipv4.rst
similarity index 87%
rename from Documentation/netlabel/cipso_ipv4.txt
rename to Documentation/netlabel/cipso_ipv4.rst
index a6075481fd60..cbd3f3231221 100644
--- a/Documentation/netlabel/cipso_ipv4.txt
+++ b/Documentation/netlabel/cipso_ipv4.rst
@@ -1,10 +1,13 @@
+===================================
NetLabel CIPSO/IPv4 Protocol Engine
-==============================================================================
+===================================
+
Paul Moore, paul.moore@hp.com
May 17, 2006
- * Overview
+Overview
+========
The NetLabel CIPSO/IPv4 protocol engine is based on the IETF Commercial
IP Security Option (CIPSO) draft from July 16, 1992. A copy of this
@@ -13,7 +16,8 @@ draft can be found in this directory
it to an RFC standard it has become a de-facto standard for labeled
networking and is used in many trusted operating systems.
- * Outbound Packet Processing
+Outbound Packet Processing
+==========================
The CIPSO/IPv4 protocol engine applies the CIPSO IP option to packets by
adding the CIPSO label to the socket. This causes all packets leaving the
@@ -24,7 +28,8 @@ label by using the NetLabel security module API; if the NetLabel "domain" is
configured to use CIPSO for packet labeling then a CIPSO IP option will be
generated and attached to the socket.
- * Inbound Packet Processing
+Inbound Packet Processing
+=========================
The CIPSO/IPv4 protocol engine validates every CIPSO IP option it finds at the
IP layer without any special handling required by the LSM. However, in order
@@ -33,7 +38,8 @@ NetLabel security module API to extract the security attributes of the packet.
This is typically done at the socket layer using the 'socket_sock_rcv_skb()'
LSM hook.
- * Label Translation
+Label Translation
+=================
The CIPSO/IPv4 protocol engine contains a mechanism to translate CIPSO security
attributes such as sensitivity level and category to values which are
@@ -42,7 +48,8 @@ Domain Of Interpretation (DOI) definition and are configured through the
NetLabel user space communication layer. Each DOI definition can have a
different security attribute mapping table.
- * Label Translation Cache
+Label Translation Cache
+=======================
The NetLabel system provides a framework for caching security attribute
mappings from the network labels to the corresponding LSM identifiers. The
diff --git a/Documentation/netlabel/draft_ietf.rst b/Documentation/netlabel/draft_ietf.rst
new file mode 100644
index 000000000000..5ed39ab8234b
--- /dev/null
+++ b/Documentation/netlabel/draft_ietf.rst
@@ -0,0 +1,5 @@
+Draft IETF CIPSO IP Security
+----------------------------
+
+ .. include:: draft-ietf-cipso-ipsecurity-01.txt
+ :literal:
diff --git a/Documentation/netlabel/index.rst b/Documentation/netlabel/index.rst
new file mode 100644
index 000000000000..47f1e0e5acd1
--- /dev/null
+++ b/Documentation/netlabel/index.rst
@@ -0,0 +1,21 @@
+:orphan:
+
+========
+NetLabel
+========
+
+.. toctree::
+ :maxdepth: 1
+
+ introduction
+ cipso_ipv4
+ lsm_interface
+
+ draft_ietf
+
+.. only:: subproject and html
+
+ Indices
+ =======
+
+ * :ref:`genindex`
diff --git a/Documentation/netlabel/introduction.txt b/Documentation/netlabel/introduction.rst
similarity index 91%
rename from Documentation/netlabel/introduction.txt
rename to Documentation/netlabel/introduction.rst
index 3caf77bcff0f..9333bbb0adc1 100644
--- a/Documentation/netlabel/introduction.txt
+++ b/Documentation/netlabel/introduction.rst
@@ -1,10 +1,13 @@
+=====================
NetLabel Introduction
-==============================================================================
+=====================
+
Paul Moore, paul.moore@hp.com
August 2, 2006
- * Overview
+Overview
+========
NetLabel is a mechanism which can be used by kernel security modules to attach
security attributes to outgoing network packets generated from user space
@@ -12,7 +15,8 @@ applications and read security attributes from incoming network packets. It
is composed of three main components, the protocol engines, the communication
layer, and the kernel security module API.
- * Protocol Engines
+Protocol Engines
+================
The protocol engines are responsible for both applying and retrieving the
network packet's security attributes. If any translation between the network
@@ -24,7 +28,8 @@ the NetLabel kernel security module API described below.
Detailed information about each NetLabel protocol engine can be found in this
directory.
- * Communication Layer
+Communication Layer
+===================
The communication layer exists to allow NetLabel configuration and monitoring
from user space. The NetLabel communication layer uses a message based
@@ -33,7 +38,8 @@ formatting of these NetLabel messages as well as the Generic NETLINK family
names can be found in the 'net/netlabel/' directory as comments in the
header files as well as in 'include/net/netlabel.h'.
- * Security Module API
+Security Module API
+===================
The purpose of the NetLabel security module API is to provide a protocol
independent interface to the underlying NetLabel protocol engines. In addition
diff --git a/Documentation/netlabel/lsm_interface.txt b/Documentation/netlabel/lsm_interface.rst
similarity index 88%
rename from Documentation/netlabel/lsm_interface.txt
rename to Documentation/netlabel/lsm_interface.rst
index 638c74f7de7f..026fc267f798 100644
--- a/Documentation/netlabel/lsm_interface.txt
+++ b/Documentation/netlabel/lsm_interface.rst
@@ -1,10 +1,13 @@
+========================================
NetLabel Linux Security Module Interface
-==============================================================================
+========================================
+
Paul Moore, paul.moore@hp.com
May 17, 2006
- * Overview
+Overview
+========
NetLabel is a mechanism which can set and retrieve security attributes from
network packets. It is intended to be used by LSM developers who want to make
@@ -12,7 +15,8 @@ use of a common code base for several different packet labeling protocols.
The NetLabel security module API is defined in 'include/net/netlabel.h' but a
brief overview is given below.
- * NetLabel Security Attributes
+NetLabel Security Attributes
+============================
Since NetLabel supports multiple different packet labeling protocols and LSMs
it uses the concept of security attributes to refer to the packet's security
@@ -24,7 +28,8 @@ configuration. It is up to the LSM developer to translate the NetLabel
security attributes into whatever security identifiers are in use for their
particular LSM.
- * NetLabel LSM Protocol Operations
+NetLabel LSM Protocol Operations
+================================
These are the functions which allow the LSM developer to manipulate the labels
on outgoing packets as well as read the labels on incoming packets. Functions
@@ -32,7 +37,8 @@ exist to operate both on sockets as well as the sk_buffs directly. These high
level functions are translated into low level protocol operations based on how
the administrator has configured the NetLabel subsystem.
- * NetLabel Label Mapping Cache Operations
+NetLabel Label Mapping Cache Operations
+=======================================
Depending on the exact configuration, translation between the network packet
label and the internal LSM security identifier can be time consuming. The
--
2.21.0
^ permalink raw reply related
* Re: What do LSMs *actually* need for checks on notifications?
From: Casey Schaufler @ 2019-06-12 18:14 UTC (permalink / raw)
To: David Howells
Cc: Stephen Smalley, Andy Lutomirski, viro, linux-usb,
linux-security-module, linux-fsdevel, linux-kernel, casey
In-Reply-To: <14576.1560361278@warthog.procyon.org.uk>
On 6/12/2019 10:41 AM, David Howells wrote:
> Casey Schaufler <casey@schaufler-ca.com> wrote:
>
>>> (4) The security attributes of the object on which the watch was set (uid,
>>> gid, mode, labels).
>> Smack needs this to set a watch on the named object (file, key, ...).
>> I am going to say that if you can't access an object you can't watch it.
> So for the things I've so far defined:
>
> (*) Keys/keyrings require View permission, but it could be Read permission
> instead - though that may get disabled if the key type does not support
> KEYCTL_READ.
View is good enough.
> (*) Mount/superblock watches - I've made these require execute permission on
> the specified directory. Could be read permission instead.
Execute is good enough.
> (*) Device events (block/usb) don't require any permissions, but currently
> only deliver hardware notifications.
How do you specify what device you want to watch?
Don't you have to access a /dev/something?
"currently" makes me nervous.
>> I think that read access is sufficient provided that no one else can
>> see what watches I've created.
> You can't find out what watches exist.
Not even your own?
>>> At the moment, when post_one_notification() wants to write a notification
>>> into a queue, it calls security_post_notification() to ask if it should be
>>> allowed to do so. This is passed (1) and (3) above plus the notification
>>> record.
>> Is "current" (2)? Smack needs (2) for the event delivery access check.
> (2) was current_cred() when watch_sb(), KEYCTL_NOTIFY, etc. was called, but
> isn't necessarily current_cred() at the point post_one_notification() is
> called. The latter is called at the point the event is generated and
> current_cred() is the creds of whatever thread that is called in (which may be
> a work_queue thread if it got deferred).
>
> At the moment, I'm storing the creds of whoever opened the queue (ie. (1)) and
> using that, but I could cache the creds of whoever created each watch
> (ie. (2)) and pass that to post_one_notification() instead.
>
> However, it should be noted that (1) is the creds of the buffer owner.
How are buffers shared? Who besides the buffer creator can use it?
>>> (e) All the points at which we walk over an object in a chain from (c) to
>>> find the watch on which we can effect (d) (eg. we walk rootwards from a
>>> mountpoint to find watches on a branch in the mount topology).
>> Smack does not require anything beyond existing checks.
> I'm glad to hear that, as this might be sufficiently impractical as to render
> it unusable with Smack. Calling i_op->permissions() a lot would suck.
>
>>> (y) What checks should be done on object destruction after final put and
>>> what contexts need to be supplied?
>> Classically there is no such thing as filesystem object deletion.
>> By making it possible to set a watch on that you've inadvertently
>> added a security relevant action to the security model. :o
> That wasn't my original intention - I intended fsmount(2) to mount directly as
> mount(2) does, but Al had other ideas.
>
> Now fsmount(2) produces a file descriptor referring to a new mount object that
> can be mounted into by move_mount(2) before being spliced into the mount
> topology by move_mount(2). However, if the fd is closed before the last step,
> close() will destroy the mount subtree attached to it (kind of quasi-unmount).
>
> That wouldn't be a problem, except that the fd from fsmount(2) can be used
> anywhere an O_PATH fd can be used - including watch_mount(2), fchdir(2), ...
> Further, FMODE_NEED_UNMOUNT gets cleared if the mount is spliced in at least
> once.
>
> Okay, having tried it you don't get an unmount event (since there's no actual
> unmount), but you do get an event to say that your watch got deleted (if the
> directory on which the watch was placed got removed from the system).
>
> So... does the "your watch got deleted" message need checking? In my
> opinion, it shouldn't get discarded because then the watcher doesn't know
> their watch went away.
Can you glean information from the watch being deleted?
I wouldn't think so, and it seems like a one-time event
from the system, so I don't think an access check would
be required.
>
> David
^ permalink raw reply
* RE: [RFC PATCH v2 2/5] x86/sgx: Require userspace to define enclave pages' protection bits
From: Xing, Cedric @ 2019-06-12 18:20 UTC (permalink / raw)
To: Christopherson, Sean J, Andy Lutomirski, q@linux.intel.com
Cc: Andy Lutomirski, Jarkko Sakkinen, Stephen Smalley, James Morris,
Serge E . Hallyn, LSM List, Paul Moore, Eric Paris,
selinux@vger.kernel.org, Jethro Beekman, Hansen, Dave,
Thomas Gleixner, Linus Torvalds, LKML, X86 ML,
linux-sgx@vger.kernel.org, Andrew Morton, nhorman@redhat.com,
npmccallum@redhat.com, Ayoun, Serge, Katz-zamir, Shay,
Huang, Haitao, Andy Shevchenko, Svahn, Kai, Borislav Petkov,
Josh Triplett, Huang, Kai, David Rientjes, Roberts, William C,
Tricca, Philip B
In-Reply-To: <20190612143405.GC20308@linux.intel.com>
> From: Christopherson, Sean J
> Sent: Wednesday, June 12, 2019 7:34 AM
>
> On Tue, Jun 11, 2019 at 05:09:28PM -0700, Andy Lutomirski wrote:
> >
> > On Jun 10, 2019, at 3:28 PM, Xing, Cedric <cedric.xing@intel.com>
> wrote:
> >
> > >> From: Andy Lutomirski [mailto:luto@kernel.org]
> > >> Sent: Monday, June 10, 2019 12:15 PM This seems like an odd
> > >> workflow. Shouldn't the #PF return back to untrusted userspace so
> > >> that the untrusted user code can make its own decision as to
> > >> whether it wants to EAUG a page there as opposed to, say, killing
> > >> the enclave or waiting to keep resource usage under control?
> > >
> > > This may seem odd to some at the first glance. But if you can think
> > > of how static heap (pre-allocated by EADD before EINIT) works, the
> > > load parses the "metadata" coming with the enclave to decide the
> > > address/size of the heap, EADDs it, and calls it done. In the case
> > > of "dynamic" heap (allocated dynamically by EAUG after EINIT), the
> > > same thing applies - the loader determines the range of the heap,
> > > tells the SGX module about it, and calls it done. Everything else is
> the between the enclave and the SGX module.
> > >
> > > In practice, untrusted code usually doesn't know much about
> > > enclaves, just like it doesn't know much about the shared objects
> > > loaded into its address space either. Without the necessary
> > > knowledge, untrusted code usually just does what it is told (via
> > > o-calls, or return value from e-calls), without judging that's right
> or wrong.
> > >
> > > When it comes to #PF like what I described, of course a signal could
> > > be sent to the untrusted code but what would it do then? Usually
> > > it'd just come back asking for a page at the fault address. So we
> > > figured it'd be more efficient to just have the kernel EAUG at #PF.
> > >
> > > Please don't get me wrong though, as I'm not dictating what the s/w
> > > flow shall be. It's just going to be a choice offered to user mode.
> > > And that choice was planned to be offered via mprotect() - i.e. a
> > > writable vma causes kernel to EAUG while a non-writable vma will
> > > result in a signal (then the user mode could decide whether to
> > > EAUG). The key point is flexibility - as we want to allow all
> > > reasonable s/w flows instead of dictating one over others. We had
> similar discussions on vDSO API before.
> > > And I think you accepted my approach because of its flexibility. Am
> > > I right?
> >
> > As long as user code can turn this off, I have no real objection. But
> > it might make sense to have it be more explicit — have an ioctl set up
> > a range as “EAUG-on-demand”.
>
> This was part of the motivation behind changing SGX_IOC_ENCLAVE_ADD_PAGE
> to SGX_IOC_ENCLAVE_ADD_REGION and adding a @flags parameter. E.g.
> adding support for "EAUG-on-demand" regions would just be a new flag.
We'll end up in some sort of interface eventually. But that's too early to discuss.
Currently what we need is the plumbing - i.e. the range has to be mmap()'ed and it cannot be PROT_NONE, otherwise vm_ops->fault() will not be reached.
>
> > But this is all currently irrelevant. We can argue about it when the
> > patches show up. :)
^ permalink raw reply
* Re: What do LSMs *actually* need for checks on notifications?
From: David Howells @ 2019-06-12 18:36 UTC (permalink / raw)
To: Casey Schaufler
Cc: dhowells, Stephen Smalley, Andy Lutomirski, viro, linux-usb,
linux-security-module, linux-fsdevel, linux-kernel
In-Reply-To: <0483c310-87c0-17b6-632e-d57b2274a32f@schaufler-ca.com>
Casey Schaufler <casey@schaufler-ca.com> wrote:
> > (*) Device events (block/usb) don't require any permissions, but currently
> > only deliver hardware notifications.
>
> How do you specify what device you want to watch?
It's a general queue.
> Don't you have to access a /dev/something?
Not at the moment. One problem is that there may not be a /dev/something for
a device (take a bridge for example), and even if it does, the device driver
doesn't necessarily have access to the path. The messages contain the device
name string as appears in dmesg ("3-7" for a USB device, for example).
I think it would be wise to limit the general queue to hardware events that
either get triggered by someone physically mucking around with the hardware or
device errors, such as bad sectors or links going up and down.
> > You can't find out what watches exist.
>
> Not even your own?
No.
> > However, it should be noted that (1) is the creds of the buffer owner.
>
> How are buffers shared? Who besides the buffer creator can use it?
When you open /dev/watch_queue, you get buffers private to that file object; a
second open of the device, even by the same process, will get different
buffers.
The buffers are 'attached' to that file and are accessed by calling mmap() on
the fd; shareability is governed by how shareable the fd and a mapping are
shareable.
> Can you glean information from the watch being deleted?
> I wouldn't think so, and it seems like a one-time event
> from the system, so I don't think an access check would
> be required.
As you say, it's a one-time message per watch. The object that got deleted
would need to be recreated, rewatched and made available to both parties.
David
^ permalink raw reply
* Re: [RFC PATCH v2 2/5] x86/sgx: Require userspace to define enclave pages' protection bits
From: Jarkko Sakkinen @ 2019-06-12 19:26 UTC (permalink / raw)
To: Sean Christopherson
Cc: Andy Lutomirski, Cedric Xing, Stephen Smalley, James Morris,
Serge E . Hallyn, LSM List, Paul Moore, Eric Paris, selinux,
Jethro Beekman, Dave Hansen, Thomas Gleixner, Linus Torvalds,
LKML, X86 ML, linux-sgx, Andrew Morton, nhorman, npmccallum,
Serge Ayoun, Shay Katz-zamir, Haitao Huang, Andy Shevchenko,
Kai Svahn, Borislav Petkov, Josh Triplett, Kai Huang,
David Rientjes, William Roberts, Philip Tricca
In-Reply-To: <20190610181744.GH15995@linux.intel.com>
On Mon, Jun 10, 2019 at 11:17:44AM -0700, Sean Christopherson wrote:
> On Mon, Jun 10, 2019 at 08:45:06PM +0300, Jarkko Sakkinen wrote:
> > On Mon, Jun 10, 2019 at 09:15:33AM -0700, Sean Christopherson wrote:
> > > > 'flags' should would renamed as 'secinfo_flags_mask' even if the name is
> > > > longish. It would use the same values as the SECINFO flags. The field in
> > > > struct sgx_encl_page should have the same name. That would express
> > > > exactly relation between SECINFO and the new field. I would have never
> > > > asked on last iteration why SECINFO is not enough with a better naming.
> > >
> > > No, these flags do not impact the EPCM protections in any way. Userspace
> > > can extend the EPCM protections without going through the kernel. The
> > > protection flags for an enclave page impact VMA/PTE protection bits.
> > >
> > > IMO, it is best to treat the EPCM as being completely separate from the
> > > kernel's EPC management.
> >
> > It is a clumsy API if permissions are not taken in the same format for
> > everything. There is no reason not to do it. The way mprotect() callback
> > just interprets the field is as VMA permissions.
>
> They are two entirely different things. The explicit protection bits are
> consumed by the kernel, while SECINFO.flags is consumed by the CPU. The
> intent is to have the protection flags be analogous to mprotect(), the
> fact that they have a similar/identical format to SECINFO is irrelevant.
>
> Calling the field secinfo_flags_mask is straight up wrong on SGX2, as
> userspace can use EMODPE to set SECINFO after the page is added. It's
> also wrong on SGX1 when adding TCS pages since SECINFO.RWX bits for TCS
> pages are forced to zero by hardware.
The new variable tells the limits on which kernel will co-operate with
the enclave. It is way more descriptive than 'flags'.
> > It would also be more future-proof just to have a mask covering all bits
> > of the SECINFO flags field.
>
> This simply doesn't work, e.g. the PENDING, MODIFIED and PR flags in the
> SECINFO are read-only from a software perspective.
It is easy to validate reserved bits from a SECINFO struct.
/Jarkko
^ permalink raw reply
* Re: [RFC PATCH v1 2/3] LSM/x86/sgx: Implement SGX specific hooks in SELinux
From: Andy Lutomirski @ 2019-06-12 19:30 UTC (permalink / raw)
To: Sean Christopherson
Cc: Stephen Smalley, Cedric Xing, LSM List, selinux, LKML, linux-sgx,
Jarkko Sakkinen, Andrew Lutomirski, James Morris, Serge E. Hallyn,
Paul Moore, Eric Paris, Jethro Beekman, Dave Hansen,
Thomas Gleixner, Linus Torvalds, Andrew Morton, nhorman,
pmccallum, Ayoun, Serge, Katz-zamir, Shay, Huang, Haitao,
Andy Shevchenko, Svahn, Kai, Borislav Petkov, Josh Triplett,
Huang, Kai, David Rientjes, Roberts, William C, Philip Tricca
In-Reply-To: <20190611220243.GB3416@linux.intel.com>
On Tue, Jun 11, 2019 at 3:02 PM Sean Christopherson
<sean.j.christopherson@intel.com> wrote:
>
> On Tue, Jun 11, 2019 at 09:40:25AM -0400, Stephen Smalley wrote:
> > I haven't looked at this code closely, but it feels like a lot of
> > SGX-specific logic embedded into SELinux that will have to be repeated or
> > reused for every security module. Does SGX not track this state itself?
>
> SGX does track equivalent state.
>
> There are three proposals on the table (I think):
Sounds about right. I've been playing with #1 and #2 (as text, not
code), and I'll post my latest thoughts on it below. But first, I
should mention that I think we've gotten a bit too caught up on
SELinux-y terminology like "EXECMOD" and "EXECMEM", which is relevant
since the kernel has very little visibility into what the enclave is
doing. Instead, I think we should think about the relevant
permissions more like this:
a) "execute code from a particular source, e.g. a file"
b) "execute code supplied from arbitrary memory outside the enclave"
c) "execute code generated within the enclave"
d) "possess WX enclave memory"
I think that any sensible policy that allows (b) should allow (a).
Similarly, any policy that allows (d) should allow (c). I don't see
any particular need for the kernel to go out of its way to ensure
these relationships, though.
We could plausibly also distinguish "execute measured code", although
I think that the details of defining and implenenting this, especially
with SGX2, could be nastier than we want to deal with. A minimal
approach that mostly ignores SGX2 would be to have another permission
"execute code supplied from outside the enclave that was not
measured". This permission would be required on top of (a) or (b),
depending on where that code comes from.
If we want to map these to existing SELinux terms, we could use
EXECUTE for (a), EXECMOD for (c), and EXECMEM for (d). (b) seems to
also map to EXECMOD or EXECMEM depending on exactly how it happens,
and I'm not sure this makes all that much sense.
>
> 1. Require userspace to explicitly specificy (maximal) enclave page
> permissions at build time. The enclave page permissions are provided
> to, and checked by, LSMs at enclave build time.
>
> Pros: Low-complexity kernel implementation, straightforward auditing
> Cons: Sullies the SGX UAPI to some extent, may increase complexity of
> SGX2 enclave loaders.
In my notes, this works like this. This is similar, but not
identical, to what Sean has been sending out.
EADD takes flags: ALLOW_READ, ALLOW_WRITE, ALLOW_EXEC. It calls a new hook:
int security_enclave_load(struct vm_area_struct *source, unsigned int flags);
(Sean passed in the secinfo protection too, but I think we agreed
that this could be omitted.) This hook will fail if ALLOW_EXEC is
requested and the LSM doesn't consider the source VMA to be
executable. Privileges (a) and (b) are implemented here.
Optionally, we can enforce noexec here.
The future EAUG ioctl takes the same flags, but it doesn't call
security_enclave_load(). (As Cedric noted, the actual user API for EAUG
is not settled, but I don't think it makes much difference here.)
EINIT takes a sigstruct pointer. SGX calls a new hook:
unsigned int security_enclave_init(struct sigstruct *sigstruct,
struct vm_area_struct *source, unsigned int flags);
This hook can return -EPERM. Otherwise it returns 0 or a combination of
flags DENY_WX and DENY_X_IF_ALLOW_WRITE. The driver saves this value.
These represent permissions (c) and (d).
If we want to have a permission for "execute code supplied from
outside the enclave that was not measured", we could have a flag like
HAS_UNMEASURED_ALLOW_EXEC_PAGE that the LSM could consider.
mmap() and mprotect() enforce the following rules:
- Deny if a PROT_ flag is requested but the corresponding ALLOW_ flag
is not set for all pages in question.
- Deny if PROT_WRITE, PROT_EXEC, and DENY_WX are all set.
- Deny if PROT_EXEC, ALLOW_WRITE, and DENY_X_IF_ALLOW_WRITE are all set.
mprotect() and mmap() do *not* call SGX-specific LSM hooks to ask for
permission, although they can optionally call an LSM hook if they hit one of
the -EPERM cases for auditing purposes.
I think this model works quite well in an SGX1 world. The main thing
that makes me uneasy about this model is that, in SGX2, it requires
that an SGX2-compatible enclave loader must pre-declare to the kernel
whether it intends for its dynamically allocated memory to be
ALLOW_EXEC. If ALLOW_EXEC is set but not actually needed, it will
still fail if DENY_X_IF_ALLOW_WRITE ends up being set. The other
version below does not have this limitation.
>
> 2. Pre-check LSM permissions and dynamically track mappings to enclave
> pages, e.g. add an SGX mprotect() hook to restrict W->X and WX
> based on the pre-checked permissions.
>
> Pros: Does not impact SGX UAPI, medium kernel complexity
> Cons: Auditing is complex/weird, requires taking enclave-specific
> lock during mprotect() to query/update tracking.
Here's how this looks in my mind. It's quite similar, except that
ALLOW_READ, ALLOW_WRITE, and ALLOW_EXEC are replaced with a little
state machine.
EADD does not take any special flags. It calls this LSM hook:
int security_enclave_load(struct vm_area_struct *source);
This hook can return -EPERM. Otherwise it 0 or ALLOC_EXEC_IF_UNMODIFIED
(i.e. 1). This hook enforces permissions (a) and (b).
The driver tracks a state for each page, and the possible states are:
- CLEAN_MAYEXEC /* no W or X VMAs have existed, but X is okay */
- CLEAN_NOEXEC /* no W or X VMAs have existed, and X is not okay */
- CLEAN_EXEC /* no W VMA has existed, but an X VMA has existed */
- DIRTY /* a W VMA has existed */
The initial state for a page is CLEAN_MAYEXEC if the hook said
ALLOW_EXEC_IF_UNMODIFIED and CLEAN_NOEXEC otherwise.
The future EAUG does not call a hook at all and puts pages into the state
CLEAN_NOEXEC. If SGX3 or later ever adds EAUG-but-don't-clear, it can
call security_enclave_load() and add CLEAN_MAYEXEC pages if appropriate.
EINIT takes a sigstruct pointer. SGX calls a new hook:
unsigned int security_enclave_init(struct sigstruct *sigstruct,
struct vm_area_struct *source, unsigned int flags);
This hook can return -EPERM. Otherwise it returns 0 or a combination of
flags DENY_WX and DENY_X_DIRTY. The driver saves this value.
These represent permissions (c) and (d).
If we want to have a permission for "execute code supplied from outside the
enclave that was not measured", we could have a flag like
HAS_UNMEASURED_CLEAN_EXEC_PAGE that the LSM could consider.
mmap() and mprotect() enforce the following rules:
- If VM_EXEC is requested and (either the page is DIRTY or VM_WRITE is
requested) and DENY_X_DIRTY, then deny.
- If VM_WRITE and VM_EXEC are both requested and DENY_WX, then deny.
- If VM_WRITE is requested, we need to update the state. If it was
CLEAN_EXEC, then we reject if DENY_X_DIRTY. Otherwise we change the
state to DIRTY.
- If VM_EXEC is requested and the page is CLEAN_NOEXEC, then deny.
mprotect() and mmap() do *not* call SGX-specific LSM hooks to ask for
permission, although they can optionally call an LSM hook if they hit one of
the -EPERM cases for auditing purposes.
Before the SIGSTRUCT is provided to the driver, the driver acts as though
DENY_X_DIRTY and DENY_WX are both set.
^ permalink raw reply
* Re: [PATCH v2 1/2] LSM: switch to blocking policy update notifiers
From: James Morris @ 2019-06-12 20:55 UTC (permalink / raw)
To: Janne Karhunen; +Cc: sds, paul, zohar, linux-integrity, linux-security-module
In-Reply-To: <20190612074456.2504-1-janne.karhunen@gmail.com>
On Wed, 12 Jun 2019, Janne Karhunen wrote:
> Atomic policy updaters are not very useful as they cannot
> usually perform the policy updates on their own. Since it
> seems that there is no strict need for the atomicity,
> switch to the blocking variant. While doing so, rename
> the functions accordingly.
>
> Changelog v2
> - Rebase to 'next-queued-testing'
>
> Signed-off-by: Janne Karhunen <janne.karhunen@gmail.com>
> Acked-by: Paul Moore <paul@paul-moore.com>
Acked-by: James Morris <jamorris@linux.microsoft.com>
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* [GIT PULL] SELinux fixes for v5.2 (#2)
From: Paul Moore @ 2019-06-12 20:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: selinux, linux-security-module, linux-kernel
Hi Linus,
Three patches for v5.2; one fixes a problem where we weren't correctly
logging raw SELinux labels, the other two fix problems where we
weren't properly checking calls to kmemdup(). Please merge for the
next v5.2-rc release.
Thanks,
-Paul
--
The following changes since commit 05174c95b83f8aca0c47b87115abb7a6387aafa5:
selinux: do not report error on connect(AF_UNSPEC) (2019-05-20 21:46:02 -0400)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git
tags/selinux-pr-20190612
for you to fetch changes up to fec6375320c6399c708fa9801f8cfbf950fee623:
selinux: fix a missing-check bug in selinux_sb_eat_lsm_opts()
(2019-06-12 12:27:26 -0400)
----------------------------------------------------------------
selinux/stable-5.2 PR 20190612
----------------------------------------------------------------
Gen Zhang (2):
selinux: fix a missing-check bug in selinux_add_mnt_opt( )
selinux: fix a missing-check bug in selinux_sb_eat_lsm_opts()
Ondrej Mosnacek (1):
selinux: log raw contexts as untrusted strings
security/selinux/avc.c | 10 ++++++++--
security/selinux/hooks.c | 39 ++++++++++++++++++++++++++++-----------
2 files changed, 36 insertions(+), 13 deletions(-)
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH 02/13] uapi: General notification ring definitions [ver #4]
From: Randy Dunlap @ 2019-06-13 14:49 UTC (permalink / raw)
To: David Howells
Cc: Darrick J. Wong, viro, raven, linux-fsdevel, linux-api,
linux-block, keyrings, linux-security-module, linux-kernel
In-Reply-To: <30226.1560432885@warthog.procyon.org.uk>
On 6/13/19 6:34 AM, David Howells wrote:
> Randy Dunlap <rdunlap@infradead.org> wrote:
>
>> What is the problem with inline functions in UAPI headers?
>
> It makes compiler problems more likely; it increases the potential for name
> collisions with userspace; it makes for more potential problems if the headers
> are imported into some other language; and it's not easy to fix a bug in one
> if userspace uses it, just in case fixing the bug breaks userspace.
>
> Further, in this case, the first of Darrick's functions (calculating the
> length) is probably reasonable, but the second is not. It should crank the
> tail pointer and then use that, but that requires
>
>>>> Also, weird multiline comment style.
>>>
>>> Not really.
>>
>> Yes really.
>
> No. It's not weird. If anything, the default style is less good for several
> reasons. I'm going to deal with this separately as I need to generate some
> stats first.
>
> David
>
OK, maybe you are objecting to the word "weird." So the multi-line comment style
that you used is not the preferred Linux kernel multi-line comment style
(except in networking code) [Documentation/process/coding-style.rst] that has been
in effect for 20+ years AFAIK.
--
~Randy
^ permalink raw reply
* Re: [RFC PATCH 2/9] x86/sgx: Do not naturally align MAP_FIXED address
From: Jarkko Sakkinen @ 2019-06-13 13:48 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Xing, Cedric, Andy Lutomirski, Christopherson, Sean J,
Stephen Smalley, James Morris, Serge E . Hallyn, LSM List,
Paul Moore, Eric Paris, selinux@vger.kernel.org, Jethro Beekman,
Hansen, Dave, Thomas Gleixner, Linus Torvalds, LKML, X86 ML,
linux-sgx@vger.kernel.org, Andrew Morton, nhorman@redhat.com,
npmccallum@redhat.com, Ayoun, Serge, Katz-zamir, Shay,
Huang, Haitao, Andy Shevchenko, Svahn, Kai, Borislav Petkov,
Josh Triplett, Huang, Kai, David Rientjes, Roberts, William C,
Tricca, Philip B
In-Reply-To: <20190606153710.GB25112@linux.intel.com>
On Thu, Jun 06, 2019 at 06:37:10PM +0300, Jarkko Sakkinen wrote:
> On Wed, Jun 05, 2019 at 01:14:04PM -0700, Andy Lutomirski wrote:
> >
> >
> > > On Jun 5, 2019, at 8:17 AM, Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> wrote:
> > >
> > >> On Tue, Jun 04, 2019 at 10:10:22PM +0000, Xing, Cedric wrote:
> > >> A bit off topic here. This mmap()/mprotect() discussion reminds me a
> > >> question (guess for Jarkko): Now that vma->vm_file->private_data keeps
> > >> a pointer to the enclave, why do we store it again in vma->vm_private?
> > >> It isn't a big deal but non-NULL vm_private does prevent mprotect()
> > >> from merging adjacent VMAs.
> > >
> > > Same semantics as with a regular mmap i.e. you can close the file and
> > > still use the mapping.
> > >
> > >
> >
> > The file should be properly refcounted — vm_file should not go away while it’s mapped.
mm already takes care of that so vm_file does not go away. Still
we need an internal refcount for enclaves to synchronize with the
swapper. In summary nothing needs to be done.
> Right, makes sense. It is easy one to change essentially just removing
> internal refcount from sgx_encl and using file for the same. I'll update
> this to my tree along with the changes to remove LKM/ACPI bits ASAP.
/Jarkko
^ permalink raw reply
* Re: [RFC 1/7] tee: optee: allow kernel pages to register as shm
From: Jarkko Sakkinen @ 2019-06-13 15:12 UTC (permalink / raw)
To: Sumit Garg
Cc: keyrings, linux-integrity, linux-security-module, jens.wiklander,
corbet, dhowells, jejb, zohar, jmorris, serge, ard.biesheuvel,
daniel.thompson, linux-doc, linux-kernel, tee-dev
In-Reply-To: <1560421833-27414-2-git-send-email-sumit.garg@linaro.org>
On Thu, Jun 13, 2019 at 04:00:27PM +0530, Sumit Garg wrote:
> Kernel pages are marked as normal type memory only so allow kernel pages
> to be registered as shared memory with OP-TEE.
>
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Just out of pure interest why this was not allowed before?
/Jarkko
^ permalink raw reply
* Re: [PATCH 02/13] uapi: General notification ring definitions [ver #4]
From: David Howells @ 2019-06-13 13:34 UTC (permalink / raw)
To: Randy Dunlap
Cc: dhowells, Darrick J. Wong, viro, raven, linux-fsdevel, linux-api,
linux-block, keyrings, linux-security-module, linux-kernel
In-Reply-To: <6b6f5bb0-1426-239b-ac9f-281e31ddcd04@infradead.org>
Randy Dunlap <rdunlap@infradead.org> wrote:
> What is the problem with inline functions in UAPI headers?
It makes compiler problems more likely; it increases the potential for name
collisions with userspace; it makes for more potential problems if the headers
are imported into some other language; and it's not easy to fix a bug in one
if userspace uses it, just in case fixing the bug breaks userspace.
Further, in this case, the first of Darrick's functions (calculating the
length) is probably reasonable, but the second is not. It should crank the
tail pointer and then use that, but that requires
> >> Also, weird multiline comment style.
> >
> > Not really.
>
> Yes really.
No. It's not weird. If anything, the default style is less good for several
reasons. I'm going to deal with this separately as I need to generate some
stats first.
David
^ permalink raw reply
* Re: [RFC 1/7] tee: optee: allow kernel pages to register as shm
From: Jarkko Sakkinen @ 2019-06-13 15:17 UTC (permalink / raw)
To: Sumit Garg
Cc: keyrings, linux-integrity, linux-security-module, jens.wiklander,
corbet, dhowells, jejb, zohar, jmorris, serge, ard.biesheuvel,
daniel.thompson, linux-doc, linux-kernel, tee-dev
In-Reply-To: <20190613151257.GA18488@linux.intel.com>
On Thu, Jun 13, 2019 at 06:12:57PM +0300, Jarkko Sakkinen wrote:
> On Thu, Jun 13, 2019 at 04:00:27PM +0530, Sumit Garg wrote:
> > Kernel pages are marked as normal type memory only so allow kernel pages
> > to be registered as shared memory with OP-TEE.
> >
> > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
>
> Just out of pure interest why this was not allowed before?
Please spare me and ignore that one :-) Obviouslly because it
was not used.
Acked-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
/Jarkko
^ permalink raw reply
* Re: [RFC 1/7] tee: optee: allow kernel pages to register as shm
From: Jarkko Sakkinen @ 2019-06-13 15:17 UTC (permalink / raw)
To: Sumit Garg
Cc: keyrings, linux-integrity, linux-security-module, jens.wiklander,
corbet, dhowells, jejb, zohar, jmorris, serge, ard.biesheuvel,
daniel.thompson, linux-doc, linux-kernel, tee-dev
In-Reply-To: <20190613151714.GC18488@linux.intel.com>
On Thu, Jun 13, 2019 at 06:17:14PM +0300, Jarkko Sakkinen wrote:
> On Thu, Jun 13, 2019 at 06:12:57PM +0300, Jarkko Sakkinen wrote:
> > On Thu, Jun 13, 2019 at 04:00:27PM +0530, Sumit Garg wrote:
> > > Kernel pages are marked as normal type memory only so allow kernel pages
> > > to be registered as shared memory with OP-TEE.
> > >
> > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> >
> > Just out of pure interest why this was not allowed before?
>
> Please spare me and ignore that one :-) Obviouslly because it
> was not used.
>
> Acked-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Actually,
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
/Jarkko
^ permalink raw reply
* Re: [RFC 2/7] tee: enable support to register kernel memory
From: Jarkko Sakkinen @ 2019-06-13 15:20 UTC (permalink / raw)
To: Sumit Garg
Cc: keyrings, linux-integrity, linux-security-module, jens.wiklander,
corbet, dhowells, jejb, zohar, jmorris, serge, ard.biesheuvel,
daniel.thompson, linux-doc, linux-kernel, tee-dev
In-Reply-To: <1560421833-27414-3-git-send-email-sumit.garg@linaro.org>
On Thu, Jun 13, 2019 at 04:00:28PM +0530, Sumit Garg wrote:
> Enable support to register kernel memory reference with TEE. This change
> will allow TEE bus drivers to register memory references.
>
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
/Jarkko
^ permalink raw reply
* Re: [RFC 4/7] KEYS: trusted: Introduce TEE based Trusted Keys
From: Jarkko Sakkinen @ 2019-06-13 15:32 UTC (permalink / raw)
To: Sumit Garg
Cc: keyrings, linux-integrity, linux-security-module, jens.wiklander,
corbet, dhowells, jejb, zohar, jmorris, serge, ard.biesheuvel,
daniel.thompson, linux-doc, linux-kernel, tee-dev
In-Reply-To: <1560421833-27414-5-git-send-email-sumit.garg@linaro.org>
On Thu, Jun 13, 2019 at 04:00:30PM +0530, Sumit Garg wrote:
> Add support for TEE based trusted keys where TEE provides the functionality
> to seal and unseal trusted keys using hardware unique key.
>
> Refer to Documentation/tee.txt for detailed information about TEE.
>
> Approach taken in this patch acts as an alternative to a TPM device in case
> platform doesn't possess one.
>
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
How does this interact with the trusted module? Why there is no update
to security/keys/trusted-encrypted.txt?
Somehow the existing trusted module needs to be re-architected to work
with either. Otherwise, this will turn out to be a mess.
/Jarkko
^ permalink raw reply
* [RFC 7/7] MAINTAINERS: Add entry for TEE based Trusted Keys
From: Sumit Garg @ 2019-06-13 10:30 UTC (permalink / raw)
To: keyrings, linux-integrity, linux-security-module
Cc: jens.wiklander, corbet, dhowells, jejb, jarkko.sakkinen, zohar,
jmorris, serge, ard.biesheuvel, daniel.thompson, linux-doc,
linux-kernel, tee-dev, Sumit Garg
In-Reply-To: <1560421833-27414-1-git-send-email-sumit.garg@linaro.org>
Add MAINTAINERS entry for TEE based Trusted Keys framework.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
MAINTAINERS | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 57f496c..db84fc4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8728,6 +8728,15 @@ F: include/keys/trusted-type.h
F: security/keys/trusted.c
F: security/keys/trusted.h
+KEYS-TEE-TRUSTED
+M: Sumit Garg <sumit.garg@linaro.org>
+L: linux-integrity@vger.kernel.org
+L: keyrings@vger.kernel.org
+S: Supported
+F: Documentation/security/keys/tee-trusted.rst
+F: include/keys/tee_trusted.h
+F: security/keys/tee_trusted.c
+
KEYS/KEYRINGS:
M: David Howells <dhowells@redhat.com>
L: keyrings@vger.kernel.org
--
2.7.4
^ permalink raw reply related
* [RFC 6/7] doc: keys: Document usage of TEE based Trusted Keys
From: Sumit Garg @ 2019-06-13 10:30 UTC (permalink / raw)
To: keyrings, linux-integrity, linux-security-module
Cc: jens.wiklander, corbet, dhowells, jejb, jarkko.sakkinen, zohar,
jmorris, serge, ard.biesheuvel, daniel.thompson, linux-doc,
linux-kernel, tee-dev, Sumit Garg
In-Reply-To: <1560421833-27414-1-git-send-email-sumit.garg@linaro.org>
Provide documentation for usage of TEE based Trusted Keys via existing
user-space "keyctl" utility. Also, document various use-cases.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
Documentation/security/keys/tee-trusted.rst | 93 +++++++++++++++++++++++++++++
1 file changed, 93 insertions(+)
create mode 100644 Documentation/security/keys/tee-trusted.rst
diff --git a/Documentation/security/keys/tee-trusted.rst b/Documentation/security/keys/tee-trusted.rst
new file mode 100644
index 0000000..ef03745
--- /dev/null
+++ b/Documentation/security/keys/tee-trusted.rst
@@ -0,0 +1,93 @@
+======================
+TEE based Trusted Keys
+======================
+
+TEE based Trusted Keys provides an alternative approach for providing Trusted
+Keys in case TPM chip isn't present.
+
+Trusted Keys use a TEE service/device both to generate and to seal the keys.
+Keys are sealed under a hardware unique key in the TEE, and only unsealed by
+the TEE.
+
+For more information about TEE, refer to ``Documentation/tee.txt``.
+
+Usage::
+
+ keyctl add trusted name "new keylen" ring
+ keyctl add trusted name "load hex_blob" ring
+ keyctl print keyid
+
+"keyctl print" returns an ascii hex copy of the sealed key, which is in format
+specific to TEE device implementation. The key length for new keys are always
+in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits).
+
+Examples of trusted key and its usage as 'master' key for encrypted key usage:
+
+More details about encrypted keys can be found here:
+``Documentation/security/keys/trusted-encrypted.rst``
+
+Create and save a trusted key named "kmk" of length 32 bytes::
+
+ $ keyctl add trusted kmk "new 32" @u
+ 754414669
+
+ $ keyctl show
+ Session Keyring
+ 827385718 --alswrv 0 65534 keyring: _uid_ses.0
+ 274124851 --alswrv 0 65534 \_ keyring: _uid.0
+ 754414669 --als-rv 0 0 \_ trusted: kmk
+
+ $ keyctl print 754414669
+ 15676790697861b422175596ae001c2f505cea2c6f3ebbc5fb08eeb1f343a07e
+
+ $ keyctl pipe 754414669 > kmk.blob
+
+Load a trusted key from the saved blob::
+
+ $ keyctl add trusted kmk "load `cat kmk.blob`" @u
+ 491638700
+
+ $ keyctl print 491638700
+ 15676790697861b422175596ae001c2f505cea2c6f3ebbc5fb08eeb1f343a07e
+
+The initial consumer of trusted keys is EVM, which at boot time needs a high
+quality symmetric key for HMAC protection of file metadata. The use of a
+TEE based trusted key provides security that the EVM key has not been
+compromised by a user level problem and tied to particular hardware.
+
+Create and save an encrypted key "evm" using the above trusted key "kmk":
+
+option 1: omitting 'format'::
+
+ $ keyctl add encrypted evm "new trusted:kmk 32" @u
+ 608915065
+
+option 2: explicitly defining 'format' as 'default'::
+
+ $ keyctl add encrypted evm "new default trusted:kmk 32" @u
+ 608915065
+
+ $ keyctl print 608915065
+ default trusted:kmk 32 f380ac588a925f488d5be007cf23e4c900b8b652ab62241c8
+ ed54906189b6659d139d619d4b51752a2645537b11fd44673f13154a65b3f595d5fb2131
+ 2fe45529ea0407c644ea4026f2a1a75661f2c9b66
+
+ $ keyctl pipe 608915065 > evm.blob
+
+Load an encrypted key "evm" from saved blob::
+
+ $ keyctl add encrypted evm "load `cat evm.blob`" @u
+ 831684262
+
+ $ keyctl print 831684262
+ default trusted:kmk 32 f380ac588a925f488d5be007cf23e4c900b8b652ab62241c8
+ ed54906189b6659d139d619d4b51752a2645537b11fd44673f13154a65b3f595d5fb2131
+ 2fe45529ea0407c644ea4026f2a1a75661f2c9b66
+
+Other uses for trusted and encrypted keys, such as for disk and file encryption
+are anticipated. In particular the 'ecryptfs' encrypted keys format can be used
+to mount an eCryptfs filesystem. More details about the usage can be found in
+the file ``Documentation/security/keys/ecryptfs.rst``.
+
+Another format 'enc32' can be used to support encrypted keys with payload size
+of 32 bytes.
--
2.7.4
^ permalink raw reply related
* Re: [RFC 6/7] doc: keys: Document usage of TEE based Trusted Keys
From: Jarkko Sakkinen @ 2019-06-13 15:34 UTC (permalink / raw)
To: Sumit Garg
Cc: keyrings, linux-integrity, linux-security-module, jens.wiklander,
corbet, dhowells, jejb, zohar, jmorris, serge, ard.biesheuvel,
daniel.thompson, linux-doc, linux-kernel, tee-dev
In-Reply-To: <1560421833-27414-7-git-send-email-sumit.garg@linaro.org>
On Thu, Jun 13, 2019 at 04:00:32PM +0530, Sumit Garg wrote:
> Provide documentation for usage of TEE based Trusted Keys via existing
> user-space "keyctl" utility. Also, document various use-cases.
>
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Sorry missed this patch. Anyway, I don't think we want multiple trusted
keys subsystems. You have to fix the existing one if you care to get
these changes in. There is no really other way around this.
/Jarkko
^ permalink raw reply
* [RFC 5/7] KEYS: encrypted: Allow TEE based trusted master keys
From: Sumit Garg @ 2019-06-13 10:30 UTC (permalink / raw)
To: keyrings, linux-integrity, linux-security-module
Cc: jens.wiklander, corbet, dhowells, jejb, jarkko.sakkinen, zohar,
jmorris, serge, ard.biesheuvel, daniel.thompson, linux-doc,
linux-kernel, tee-dev, Sumit Garg
In-Reply-To: <1560421833-27414-1-git-send-email-sumit.garg@linaro.org>
Allow search for TEE based trusted keys to act as master keys in case
TPM device is not present.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
security/keys/encrypted-keys/masterkey_trusted.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/security/keys/encrypted-keys/masterkey_trusted.c b/security/keys/encrypted-keys/masterkey_trusted.c
index c68528a..cfac27f 100644
--- a/security/keys/encrypted-keys/masterkey_trusted.c
+++ b/security/keys/encrypted-keys/masterkey_trusted.c
@@ -23,6 +23,9 @@
* Trusted keys are sealed to PCRs and other metadata. Although userspace
* manages both trusted/encrypted key-types, like the encrypted key type
* data, trusted key type data is not visible decrypted from userspace.
+ *
+ * Also, check for alternate trusted keys provided via TEE in case there
+ * is no TPM available.
*/
struct key *request_trusted_key(const char *trusted_desc,
const u8 **master_key, size_t *master_keylen)
@@ -31,8 +34,11 @@ struct key *request_trusted_key(const char *trusted_desc,
struct key *tkey;
tkey = request_key(&key_type_trusted, trusted_desc, NULL);
- if (IS_ERR(tkey))
- goto error;
+ if (IS_ERR(tkey)) {
+ tkey = request_key(&key_type_tee_trusted, trusted_desc, NULL);
+ if (IS_ERR(tkey))
+ goto error;
+ }
down_read(&tkey->sem);
tpayload = tkey->payload.data[0];
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox