[SELinux-notebook PATCH] onjects.md: some clarifications

[SELinux-notebook PATCH] onjects.md: some clarifications

[Dominick Grift]

Signed-off-by: Dominick Grift <dominick.grift@defensec.nl>
---
 src/objects.md | 24 ++++++++++++++++++++++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/src/objects.md b/src/objects.md
index 58664ef..aadb539 100644
--- a/src/objects.md
+++ b/src/objects.md
@@ -110,14 +110,20 @@ objects is managed by the system and generally unseen by the users
 (until labeling goes wrong !!). As processes and objects are created and
 destroyed, they either:
 
-1.  Inherit their labels from the parent process or object.
+1.  Inherit their labels from the parent process or object. The policy
+    default type, role and range statements can be used to change the
+    behavior as discussed in the [**Default Rules**](default_rules.md#default-object-rules)
+    section.
 2.  The policy type, role and range transition statements allow a
     different label to be assigned as discussed in the
     [**Domain and Object Transitions**](domain_object_transitions.md#domain-and-object-transitions)
     section.
 3.  SELinux-aware applications can enforce a new label (with the
     policies approval of course) using the **libselinux** API
-    functions.
+    functions. The `process setfscreate` access vector can be used to
+    allow subjects to create files with a new label programmatically
+    using the ***setfscreatecon**(3)* function, overriding default
+    rules and transition statements.
 4.  An object manager (OM) can enforce a default label that can either
     be built into the OM or obtained via a configuration file (such as
     those used by
@@ -269,6 +275,20 @@ and manage their transition:
 
 `type_transition`, `role_transition` and `range_transition`
 
+SELinux-aware applications can enforce a new label (with the policies
+approval of course) using the **libselinux** API functions. The
+`process setexec`, `process setkeycreate` and `process setsockcreate`
+access vectors can be used to allow subjects to label processes,
+kernel keyrings, and sockets programmatically using the
+***setexec**(3)*, ***setkeycreatecon**(3)* and
+***setsockcreatecon**(3)* functions respectively, overriding
+transition statements.
+
+The `kernel` and `unlabeled` **initial security identifiers** are used
+to associate specified labels with subjects that were left unlabeled
+due to initialization or with subjects that had their label
+invalidated due to policy changes at runtime respectively.
+
 ### Object Reuse
 
 As GNU / Linux runs it creates instances of objects and manages the
-- 
2.27.0

[SELinux-notebook PATCH v2] objects.md: some clarifications

[Dominick Grift]

v2: fixes patch description
Signed-off-by: Dominick Grift <dominick.grift@defensec.nl>
---
 src/objects.md | 24 ++++++++++++++++++++++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/src/objects.md b/src/objects.md
index 58664ef..aadb539 100644
--- a/src/objects.md
+++ b/src/objects.md
@@ -110,14 +110,20 @@ objects is managed by the system and generally unseen by the users
 (until labeling goes wrong !!). As processes and objects are created and
 destroyed, they either:
 
-1.  Inherit their labels from the parent process or object.
+1.  Inherit their labels from the parent process or object. The policy
+    default type, role and range statements can be used to change the
+    behavior as discussed in the [**Default Rules**](default_rules.md#default-object-rules)
+    section.
 2.  The policy type, role and range transition statements allow a
     different label to be assigned as discussed in the
     [**Domain and Object Transitions**](domain_object_transitions.md#domain-and-object-transitions)
     section.
 3.  SELinux-aware applications can enforce a new label (with the
     policies approval of course) using the **libselinux** API
-    functions.
+    functions. The `process setfscreate` access vector can be used to
+    allow subjects to create files with a new label programmatically
+    using the ***setfscreatecon**(3)* function, overriding default
+    rules and transition statements.
 4.  An object manager (OM) can enforce a default label that can either
     be built into the OM or obtained via a configuration file (such as
     those used by
@@ -269,6 +275,20 @@ and manage their transition:
 
 `type_transition`, `role_transition` and `range_transition`
 
+SELinux-aware applications can enforce a new label (with the policies
+approval of course) using the **libselinux** API functions. The
+`process setexec`, `process setkeycreate` and `process setsockcreate`
+access vectors can be used to allow subjects to label processes,
+kernel keyrings, and sockets programmatically using the
+***setexec**(3)*, ***setkeycreatecon**(3)* and
+***setsockcreatecon**(3)* functions respectively, overriding
+transition statements.
+
+The `kernel` and `unlabeled` **initial security identifiers** are used
+to associate specified labels with subjects that were left unlabeled
+due to initialization or with subjects that had their label
+invalidated due to policy changes at runtime respectively.
+
 ### Object Reuse
 
 As GNU / Linux runs it creates instances of objects and manages the
-- 
2.27.0

Re: [SELinux-notebook PATCH v2] objects.md: some clarifications

[Richard Haines]

On Fri, 2020-07-10 at 09:14 +0200, Dominick Grift wrote:
> v2: fixes patch description
> Signed-off-by: Dominick Grift <dominick.grift@defensec.nl>
> ---
>  src/objects.md | 24 ++++++++++++++++++++++--
>  1 file changed, 22 insertions(+), 2 deletions(-)
> 

Acked-by: Richard Haines <richard_c_haines@btinternet.com>

> diff --git a/src/objects.md b/src/objects.md
> index 58664ef..aadb539 100644
> --- a/src/objects.md
> +++ b/src/objects.md
> @@ -110,14 +110,20 @@ objects is managed by the system and generally
> unseen by the users
>  (until labeling goes wrong !!). As processes and objects are created
> and
>  destroyed, they either:
>  
> -1.  Inherit their labels from the parent process or object.
> +1.  Inherit their labels from the parent process or object. The
> policy
> +    default type, role and range statements can be used to change
> the
> +    behavior as discussed in the [**Default
> Rules**](default_rules.md#default-object-rules)
> +    section.
>  2.  The policy type, role and range transition statements allow a
>      different label to be assigned as discussed in the
>      [**Domain and Object
> Transitions**](domain_object_transitions.md#domain-and-object-
> transitions)
>      section.
>  3.  SELinux-aware applications can enforce a new label (with the
>      policies approval of course) using the **libselinux** API
> -    functions.
> +    functions. The `process setfscreate` access vector can be used
> to
> +    allow subjects to create files with a new label programmatically
> +    using the ***setfscreatecon**(3)* function, overriding default
> +    rules and transition statements.
>  4.  An object manager (OM) can enforce a default label that can
> either
>      be built into the OM or obtained via a configuration file (such
> as
>      those used by
> @@ -269,6 +275,20 @@ and manage their transition:
>  
>  `type_transition`, `role_transition` and `range_transition`
>  
> +SELinux-aware applications can enforce a new label (with the
> policies
> +approval of course) using the **libselinux** API functions. The
> +`process setexec`, `process setkeycreate` and `process
> setsockcreate`
> +access vectors can be used to allow subjects to label processes,
> +kernel keyrings, and sockets programmatically using the
> +***setexec**(3)*, ***setkeycreatecon**(3)* and
> +***setsockcreatecon**(3)* functions respectively, overriding
> +transition statements.
> +
> +The `kernel` and `unlabeled` **initial security identifiers** are
> used
> +to associate specified labels with subjects that were left unlabeled
> +due to initialization or with subjects that had their label
> +invalidated due to policy changes at runtime respectively.
> +
>  ### Object Reuse
>  
>  As GNU / Linux runs it creates instances of objects and manages the

Re: [SELinux-notebook PATCH v2] objects.md: some clarifications

[Paul Moore]

On Fri, Jul 10, 2020 at 3:14 AM Dominick Grift
<dominick.grift@defensec.nl> wrote:
>
> v2: fixes patch description
> Signed-off-by: Dominick Grift <dominick.grift@defensec.nl>

Thanks for the patch, but just like any other project, it would be
nice to see a patch description here.  You can also move the changelog
portion of the patch below a "--" delimiter so it doesn't get caught
up in the main description (changelogs aren't quite as useful once the
patch has been committed to the tree).

> ---
>  src/objects.md | 24 ++++++++++++++++++++++--
>  1 file changed, 22 insertions(+), 2 deletions(-)

...

> @@ -269,6 +275,20 @@ and manage their transition:
>
>  `type_transition`, `role_transition` and `range_transition`
>
> +SELinux-aware applications can enforce a new label (with the policies

As someone who is barely fluent in one language I hate to criticize
others when they are writing in their non-native language, but I think
this should be "policy's" not "policies".

> +approval of course) using the **libselinux** API functions. The
> +`process setexec`, `process setkeycreate` and `process setsockcreate`
> +access vectors can be used to allow subjects to label processes,
> +kernel keyrings, and sockets programmatically using the
> +***setexec**(3)*, ***setkeycreatecon**(3)* and
> +***setsockcreatecon**(3)* functions respectively, overriding
> +transition statements.
> +
> +The `kernel` and `unlabeled` **initial security identifiers** are used
> +to associate specified labels with subjects that were left unlabeled
> +due to initialization or with subjects that had their label
> +invalidated due to policy changes at runtime respectively.

That looks like a good definition for "unlabeled", but it doesn't look
like you've defined the "kernel" isid?

>  ### Object Reuse
>
>  As GNU / Linux runs it creates instances of objects and manages the
> --
> 2.27.0

-- 
paul moore
www.paul-moore.com

Re: [SELinux-notebook PATCH v2] objects.md: some clarifications

[Dominick Grift]

Paul Moore <paul@paul-moore.com> writes:

> On Fri, Jul 10, 2020 at 3:14 AM Dominick Grift
> <dominick.grift@defensec.nl> wrote:
>>
>> v2: fixes patch description
>> Signed-off-by: Dominick Grift <dominick.grift@defensec.nl>
>
> Thanks for the patch, but just like any other project, it would be
> nice to see a patch description here.  You can also move the changelog
> portion of the patch below a "--" delimiter so it doesn't get caught
> up in the main description (changelogs aren't quite as useful once the
> patch has been committed to the tree).

Thanks. I will redo it

>
>> ---
>>  src/objects.md | 24 ++++++++++++++++++++++--
>>  1 file changed, 22 insertions(+), 2 deletions(-)
>
> ...
>
>> @@ -269,6 +275,20 @@ and manage their transition:
>>
>>  `type_transition`, `role_transition` and `range_transition`
>>
>> +SELinux-aware applications can enforce a new label (with the policies
>
> As someone who is barely fluent in one language I hate to criticize
> others when they are writing in their non-native language, but I think
> this should be "policy's" not "policies".

I appreciate these corrections and will apply that with a v3

>
>> +approval of course) using the **libselinux** API functions. The
>> +`process setexec`, `process setkeycreate` and `process setsockcreate`
>> +access vectors can be used to allow subjects to label processes,
>> +kernel keyrings, and sockets programmatically using the
>> +***setexec**(3)*, ***setkeycreatecon**(3)* and
>> +***setsockcreatecon**(3)* functions respectively, overriding
>> +transition statements.
>> +
>> +The `kernel` and `unlabeled` **initial security identifiers** are used
>> +to associate specified labels with subjects that were left unlabeled
>> +due to initialization or with subjects that had their label
>> +invalidated due to policy changes at runtime respectively.
>
> That looks like a good definition for "unlabeled", but it doesn't look
> like you've defined the "kernel" isid?

I did (note the "respectively") but maybe I wrote it down in a less than optimal way?:

kernel: "are used to associate specified labels with subjects that were
left unlabeled due to initialization"

unlabeled: "(are used to associate specified labels) with subjects that
had their label invalidated due to policy changes at runtime"

>
>>  ### Object Reuse
>>
>>  As GNU / Linux runs it creates instances of objects and manages the
>> --
>> 2.27.0

-- 
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift

[SELinux-notebook PATCH v3] objects.md: some clarifications

[Dominick Grift]

Elaborate is bit on labeling. Touch on the significance of the default statement, on various av permissions related to labeling using the libselinux API, and on how the kernel and unlabeled initial security identifiers are used to address labeling challenges in special cases such as initialization and failover respectively.

Signed-off-by: Dominick Grift <dominick.grift@defensec.nl>
---

v2: fixes patch description
v3: adding patch description, s/policies/policy's/, spit unlabeled and kernel descriptions to clarify

 src/objects.md | 29 ++++++++++++++++++++++++++---
 1 file changed, 26 insertions(+), 3 deletions(-)

diff --git a/src/objects.md b/src/objects.md
index 58664ef..55c7ea1 100644
--- a/src/objects.md
+++ b/src/objects.md
@@ -110,14 +110,20 @@ objects is managed by the system and generally unseen by the users
 (until labeling goes wrong !!). As processes and objects are created and
 destroyed, they either:
 
-1.  Inherit their labels from the parent process or object.
+1.  Inherit their labels from the parent process or object. The policy
+    default type, role and range statements can be used to change the
+    behavior as discussed in the [**Default Rules**](default_rules.md#default-object-rules)
+    section.
 2.  The policy type, role and range transition statements allow a
     different label to be assigned as discussed in the
     [**Domain and Object Transitions**](domain_object_transitions.md#domain-and-object-transitions)
     section.
 3.  SELinux-aware applications can enforce a new label (with the
-    policies approval of course) using the **libselinux** API
-    functions.
+    policy's approval of course) using the **libselinux** API
+    functions. The `process setfscreate` access vector can be used to
+    allow subjects to create files with a new label programmatically
+    using the ***setfscreatecon**(3)* function, overriding default
+    rules and transition statements.
 4.  An object manager (OM) can enforce a default label that can either
     be built into the OM or obtained via a configuration file (such as
     those used by
@@ -269,6 +275,23 @@ and manage their transition:
 
 `type_transition`, `role_transition` and `range_transition`
 
+SELinux-aware applications can enforce a new label (with the policy's
+approval of course) using the **libselinux** API functions. The
+`process setexec`, `process setkeycreate` and `process setsockcreate`
+access vectors can be used to allow subjects to label processes,
+kernel keyrings, and sockets programmatically using the
+***setexec**(3)*, ***setkeycreatecon**(3)* and
+***setsockcreatecon**(3)* functions respectively, overriding
+transition statements.
+
+The `kernel` **initial security identifier** is used to associate
+specified labels with subjects that were left unlabeled due to
+initialization.
+
+The `unlabeled` **initial security identifier** is used
+to associate specified labels with subjects that had their label
+invalidated due to policy changes at runtime.
+
 ### Object Reuse
 
 As GNU / Linux runs it creates instances of objects and manages the
-- 
2.27.0

[SELinux-notebook PATCH v4] objects.md: some clarifications

[Dominick Grift]

Elaborate on labeling. Touch on the significance of the default statement, on various av permissions related to labeling using the libselinux API, and on how the kernel and unlabeled initial security identifiers are used to address labeling challenges in special cases such as initialization and failover respectively.

Signed-off-by: Dominick Grift <dominick.grift@defensec.nl>
---
v2: fixes patch description
v3: adding patch description, s/policies/policy's/, split unlabeled and kernel descriptions for clarity
v4: fixes another typo in description and emphasize system initialization a bit

src/objects.md | 29 ++++++++++++++++++++++++++---
 1 file changed, 26 insertions(+), 3 deletions(-)

diff --git a/src/objects.md b/src/objects.md
index 58664ef..c67787d 100644
--- a/src/objects.md
+++ b/src/objects.md
@@ -110,14 +110,20 @@ objects is managed by the system and generally unseen by the users
 (until labeling goes wrong !!). As processes and objects are created and
 destroyed, they either:
 
-1.  Inherit their labels from the parent process or object.
+1.  Inherit their labels from the parent process or object. The policy
+    default type, role and range statements can be used to change the
+    behavior as discussed in the [**Default Rules**](default_rules.md#default-object-rules)
+    section.
 2.  The policy type, role and range transition statements allow a
     different label to be assigned as discussed in the
     [**Domain and Object Transitions**](domain_object_transitions.md#domain-and-object-transitions)
     section.
 3.  SELinux-aware applications can enforce a new label (with the
-    policies approval of course) using the **libselinux** API
-    functions.
+    policy's approval of course) using the **libselinux** API
+    functions. The `process setfscreate` access vector can be used to
+    allow subjects to create files with a new label programmatically
+    using the ***setfscreatecon**(3)* function, overriding default
+    rules and transition statements.
 4.  An object manager (OM) can enforce a default label that can either
     be built into the OM or obtained via a configuration file (such as
     those used by
@@ -269,6 +275,23 @@ and manage their transition:
 
 `type_transition`, `role_transition` and `range_transition`
 
+SELinux-aware applications can enforce a new label (with the policy's
+approval of course) using the **libselinux** API functions. The
+`process setexec`, `process setkeycreate` and `process setsockcreate`
+access vectors can be used to allow subjects to label processes,
+kernel keyrings, and sockets programmatically using the
+***setexec**(3)*, ***setkeycreatecon**(3)* and
+***setsockcreatecon**(3)* functions respectively, overriding
+transition statements.
+
+The `kernel` **initial security identifier** is used to associate
+specified labels with subjects that were left unlabeled due to
+system initialization.
+
+The `unlabeled` **initial security identifier** is used
+to associate specified labels with subjects that had their label
+invalidated due to policy changes at runtime.
+
 ### Object Reuse
 
 As GNU / Linux runs it creates instances of objects and manages the
-- 
2.27.0

Re: [SELinux-notebook PATCH v4] objects.md: some clarifications

[Paul Moore]

On Thu, Jul 16, 2020 at 8:18 AM Dominick Grift
<dominick.grift@defensec.nl> wrote:
>
> Elaborate on labeling. Touch on the significance of the default statement, on various av permissions related to labeling using the libselinux API, and on how the kernel and unlabeled initial security identifiers are used to address labeling challenges in special cases such as initialization and failover respectively.
>
> Signed-off-by: Dominick Grift <dominick.grift@defensec.nl>
> ---
> v2: fixes patch description
> v3: adding patch description, s/policies/policy's/, split unlabeled and kernel descriptions for clarity
> v4: fixes another typo in description and emphasize system initialization a bit
>
> src/objects.md | 29 ++++++++++++++++++++++++++---
>  1 file changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/src/objects.md b/src/objects.md
> index 58664ef..c67787d 100644
> --- a/src/objects.md
> +++ b/src/objects.md
> @@ -110,14 +110,20 @@ objects is managed by the system and generally unseen by the users
>  (until labeling goes wrong !!). As processes and objects are created and
>  destroyed, they either:
>
> -1.  Inherit their labels from the parent process or object.
> +1.  Inherit their labels from the parent process or object. The policy
> +    default type, role and range statements can be used to change the
> +    behavior as discussed in the [**Default Rules**](default_rules.md#default-object-rules)
> +    section.
>  2.  The policy type, role and range transition statements allow a
>      different label to be assigned as discussed in the
>      [**Domain and Object Transitions**](domain_object_transitions.md#domain-and-object-transitions)
>      section.
>  3.  SELinux-aware applications can enforce a new label (with the
> -    policies approval of course) using the **libselinux** API
> -    functions.
> +    policy's approval of course) using the **libselinux** API
> +    functions. The `process setfscreate` access vector can be used to
> +    allow subjects to create files with a new label programmatically
> +    using the ***setfscreatecon**(3)* function, overriding default
> +    rules and transition statements.
>  4.  An object manager (OM) can enforce a default label that can either
>      be built into the OM or obtained via a configuration file (such as
>      those used by
> @@ -269,6 +275,23 @@ and manage their transition:
>
>  `type_transition`, `role_transition` and `range_transition`
>
> +SELinux-aware applications can enforce a new label (with the policy's
> +approval of course) using the **libselinux** API functions. The
> +`process setexec`, `process setkeycreate` and `process setsockcreate`
> +access vectors can be used to allow subjects to label processes,
> +kernel keyrings, and sockets programmatically using the
> +***setexec**(3)*, ***setkeycreatecon**(3)* and
> +***setsockcreatecon**(3)* functions respectively, overriding
> +transition statements.
> +
> +The `kernel` **initial security identifier** is used to associate
> +specified labels with subjects that were left unlabeled due to
> +system initialization.

You are iterating faster than I can review the patches ;)  Please
don't misunderstand, I'm very happy you're contributing to the
notebook; I was hoping people would get involved and I'm glad to see
that is happening.

That said, while it is true that there are a few objects that are
initially assigned the "kernel" isid, those should gain proper labels
as they complete the initialization process, unless of course they are
actually owned by the kernel.  Which brings me to the next point, some
objects are legitimately owned by the kernel, the fact that they are
labeled with the "kernel" isid is intentional.  The same holds true
for the "kernel" isid as a subject label, in cases where you see the
"kernel" isid as a subject, it is actually the kernel acting on
something.

> +The `unlabeled` **initial security identifier** is used
> +to associate specified labels with subjects that had their label
> +invalidated due to policy changes at runtime.
> +
>  ### Object Reuse
>
>  As GNU / Linux runs it creates instances of objects and manages the
> --
> 2.27.0

-- 
paul moore
www.paul-moore.com

Re: [SELinux-notebook PATCH v4] objects.md: some clarifications

[Dominick Grift]

On 7/17/20 3:36 AM, Paul Moore wrote:
> On Thu, Jul 16, 2020 at 8:18 AM Dominick Grift
> <dominick.grift@defensec.nl> wrote:
>>
>> Elaborate on labeling. Touch on the significance of the default statement, on various av permissions related to labeling using the libselinux API, and on how the kernel and unlabeled initial security identifiers are used to address labeling challenges in special cases such as initialization and failover respectively.
>>

<snip>

> The same holds true
> for the "kernel" isid as a subject label, in cases where you see the
> "kernel" isid as a subject, it is actually the kernel acting on
> something.
> 

Thanks

In my experience, processes other than kernel threads can end up
associated with the kernel sid.

One notable example is plymouthd which is run from the initramfs and
will still be there for a short while after systemd/init loads policy.
But AFAIK any process that is started from the initramfs and that
persists after policy is loaded essentially ends up with the kernel isid.

So even though practically it is generally the kernel threads that
remain visibly associated with kernel sid to the naked eye, In actuality
it in my experience boils down to "subjects that were left unlabeled due
to system initialization", whether its the kernel or some long running
process started before SELinux was initializaed.

[SELinux-notebook PATCH v5] objects.md: some clarifications

[Dominick Grift]

Elaborate on labeling. Touch on the significance of the default statement, on various av permissions related to labeling using the libselinux API, and on how the kernel and unlabeled initial security identifiers are used to address labeling challenges in special cases such as initialization and failover respectively.

Signed-off-by: Dominick Grift <dominick.grift@defensec.nl>
---

v2: fixes patch description
v3: adding patch description, s/policies/policy's/, split unlabeled and kernel descriptions for clarity
v4: fixes another typo in description and emphasize system initialization a bit
v5: emphasize kernel threads with kernel isid description

 src/objects.md | 29 ++++++++++++++++++++++++++---
 1 file changed, 26 insertions(+), 3 deletions(-)

diff --git a/src/objects.md b/src/objects.md
index 58664ef..70877b0 100644
--- a/src/objects.md
+++ b/src/objects.md
@@ -110,14 +110,20 @@ objects is managed by the system and generally unseen by the users
 (until labeling goes wrong !!). As processes and objects are created and
 destroyed, they either:
 
-1.  Inherit their labels from the parent process or object.
+1.  Inherit their labels from the parent process or object. The policy
+    default type, role and range statements can be used to change the
+    behavior as discussed in the [**Default Rules**](default_rules.md#default-object-rules)
+    section.
 2.  The policy type, role and range transition statements allow a
     different label to be assigned as discussed in the
     [**Domain and Object Transitions**](domain_object_transitions.md#domain-and-object-transitions)
     section.
 3.  SELinux-aware applications can enforce a new label (with the
-    policies approval of course) using the **libselinux** API
-    functions.
+    policy's approval of course) using the **libselinux** API
+    functions. The `process setfscreate` access vector can be used to
+    allow subjects to create files with a new label programmatically
+    using the ***setfscreatecon**(3)* function, overriding default
+    rules and transition statements.
 4.  An object manager (OM) can enforce a default label that can either
     be built into the OM or obtained via a configuration file (such as
     those used by
@@ -269,6 +275,23 @@ and manage their transition:
 
 `type_transition`, `role_transition` and `range_transition`
 
+SELinux-aware applications can enforce a new label (with the policy's
+approval of course) using the **libselinux** API functions. The
+`process setexec`, `process setkeycreate` and `process setsockcreate`
+access vectors can be used to allow subjects to label processes,
+kernel keyrings, and sockets programmatically using the
+***setexec**(3)*, ***setkeycreatecon**(3)* and
+***setsockcreatecon**(3)* functions respectively, overriding
+transition statements.
+
+The `kernel` **initial security identifier** is used to associate
+specified labels with subjects that were left unlabeled due to
+system initialization, for example kernel threads.
+
+The `unlabeled` **initial security identifier** is used
+to associate specified labels with subjects that had their label
+invalidated due to policy changes at runtime.
+
 ### Object Reuse
 
 As GNU / Linux runs it creates instances of objects and manages the
-- 
2.27.0

[SELinux-notebook PATCH v6] objects.md: some clarifications

[Dominick Grift]

Elaborate on labeling. Touch on the significance of the default statement, on various av permissions related to labeling using the libselinux API, and on how the kernel and unlabeled initial security identifiers are used to address labeling challenges in special cases such as initialization and failover respectively.

Signed-off-by: Dominick Grift <dominick.grift@defensec.nl>
---
v2: fixes patch description
v3: adding patch description, s/policies/policy's/, split unlabeled and kernel descriptions for clarity
v4: fixes another typo in description and emphasize system initialization a bit
v5: emphasize kernel threads with kernel isid description
v6: forgot to mention defaultuser, can only associate one label with isids

 src/objects.md | 29 ++++++++++++++++++++++++++---
 1 file changed, 26 insertions(+), 3 deletions(-)

diff --git a/src/objects.md b/src/objects.md
index 58664ef..d27f881 100644
--- a/src/objects.md
+++ b/src/objects.md
@@ -110,14 +110,20 @@ objects is managed by the system and generally unseen by the users
 (until labeling goes wrong !!). As processes and objects are created and
 destroyed, they either:
 
-1.  Inherit their labels from the parent process or object.
+1.  Inherit their labels from the parent process or object. The policy
+    default user, type, role and range statements can be used to
+	change the behavior as discussed in the [**Default Rules**](default_rules.md#default-object-rules)
+    section.
 2.  The policy type, role and range transition statements allow a
     different label to be assigned as discussed in the
     [**Domain and Object Transitions**](domain_object_transitions.md#domain-and-object-transitions)
     section.
 3.  SELinux-aware applications can enforce a new label (with the
-    policies approval of course) using the **libselinux** API
-    functions.
+    policy's approval of course) using the **libselinux** API
+    functions. The `process setfscreate` access vector can be used to
+    allow subjects to create files with a new label programmatically
+    using the ***setfscreatecon**(3)* function, overriding default
+    rules and transition statements.
 4.  An object manager (OM) can enforce a default label that can either
     be built into the OM or obtained via a configuration file (such as
     those used by
@@ -269,6 +275,23 @@ and manage their transition:
 
 `type_transition`, `role_transition` and `range_transition`
 
+SELinux-aware applications can enforce a new label (with the policy's
+approval of course) using the **libselinux** API functions. The
+`process setexec`, `process setkeycreate` and `process setsockcreate`
+access vectors can be used to allow subjects to label processes,
+kernel keyrings, and sockets programmatically using the
+***setexec**(3)*, ***setkeycreatecon**(3)* and
+***setsockcreatecon**(3)* functions respectively, overriding
+transition statements.
+
+The `kernel` **initial security identifier** is used to associate
+specified a label with subjects that were left unlabeled due to
+system initialization, for example kernel threads.
+
+The `unlabeled` **initial security identifier** is used
+to associate a specified label with subjects that had their label
+invalidated due to policy changes at runtime.
+
 ### Object Reuse
 
 As GNU / Linux runs it creates instances of objects and manages the
-- 
2.27.0

Re: [SELinux-notebook PATCH v6] objects.md: some clarifications

[Stephen Smalley]

On Sun, Jul 19, 2020 at 5:45 AM Dominick Grift
<dominick.grift@defensec.nl> wrote:
>
> Elaborate on labeling. Touch on the significance of the default statement, on various av permissions related to labeling using the libselinux API, and on how the kernel and unlabeled initial security identifiers are used to address labeling challenges in special cases such as initialization and failover respectively.
>
> Signed-off-by: Dominick Grift <dominick.grift@defensec.nl>
> ---

> diff --git a/src/objects.md b/src/objects.md
> index 58664ef..d27f881 100644
> --- a/src/objects.md
> +++ b/src/objects.md
> +    policy's approval of course) using the **libselinux** API
> +    functions. The `process setfscreate` access vector can be used to

process setfscreate is a permission.  An access vector is a set of
permissions. The access vector definitions in the policy specify the
set of permissions associated with each class.

> @@ -269,6 +275,23 @@ and manage their transition:
>
>  `type_transition`, `role_transition` and `range_transition`
>
> +SELinux-aware applications can enforce a new label (with the policy's

I don't think you originated this language but technically it should
be "can assign a new label"
or "specify a particular label" or similar, not "enforce a new label".

> +The `kernel` **initial security identifier** is used to associate
> +specified a label with subjects that were left unlabeled due to
> +system initialization, for example kernel threads.

The kernel SID is used for kernel objects, including kernel threads
(both those that are created during initialization but also kernel
threads created later), kernel-private sockets, synthetic objects
representing kernel resources (e.g. the "system" class), etc.  It is
true that processes created prior to initial policy load will also be
in the kernel SID until/unless there is a policy loaded and either a
policy-defined transition or an explicit setcon or setexeccon+execve,
but that's just the typical default inheritance from creating task
behavior for processes.

> +
> +The `unlabeled` **initial security identifier** is used
> +to associate a specified label with subjects that had their label
> +invalidated due to policy changes at runtime.

It is also assigned as the initial state for various objects e.g.
inodes, superblocks, etc until they reach a point where a more
specific label can be determined e.g. from an xattr or from policy.
The context associated with the unlabeled SID is used as the fallback
context for both subjects and objects when their label is invalidated
by a policy reload (their SID is unchanged but the SID is
transparently remapped to the unlabeled context).

[SELinux-notebook PATCH v7] objects.md: some clarifications

[Dominick Grift]

Elaborate on labeling. Touch on the significance of the default statement, on various av permissions related to labeling using the libselinux API, and on how the kernel and unlabeled initial security identifiers are used to address labeling challenges in special cases such as initialization and failover respectively.

Signed-off-by: Dominick Grift <dominick.grift@defensec.nl>
---
v2: fixes patch description
v3: adding patch description, s/policies/policy's/, split unlabeled and kernel descriptions for clarity
v4: fixes another typo in description and emphasize system initialization a bit
v5: emphasize kernel threads with kernel isid description
v6: forgot to mention defaultuser, can only associate one label with isids
v7: copied and pasted feedback from Stephen Smalley

 src/objects.md | 47 +++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 43 insertions(+), 4 deletions(-)

diff --git a/src/objects.md b/src/objects.md
index 58664ef..4f53446 100644
--- a/src/objects.md
+++ b/src/objects.md
@@ -110,14 +110,20 @@ objects is managed by the system and generally unseen by the users
 (until labeling goes wrong !!). As processes and objects are created and
 destroyed, they either:
 
-1.  Inherit their labels from the parent process or object.
+1.  Inherit their labels from the parent process or object. The policy
+    default user, type, role and range statements can be used to
+	change the behavior as discussed in the [**Default Rules**](default_rules.md#default-object-rules)
+    section.
 2.  The policy type, role and range transition statements allow a
     different label to be assigned as discussed in the
     [**Domain and Object Transitions**](domain_object_transitions.md#domain-and-object-transitions)
     section.
-3.  SELinux-aware applications can enforce a new label (with the
-    policies approval of course) using the **libselinux** API
-    functions.
+3.  SELinux-aware applications can assign a new label (with the
+    policy's approval of course) using the **libselinux** API
+    functions. The `process setfscreate` permission can be used to
+    allow subjects to create files with a new label programmatically
+    using the ***setfscreatecon**(3)* function, overriding default
+    rules and transition statements.
 4.  An object manager (OM) can enforce a default label that can either
     be built into the OM or obtained via a configuration file (such as
     those used by
@@ -269,6 +275,39 @@ and manage their transition:
 
 `type_transition`, `role_transition` and `range_transition`
 
+SELinux-aware applications can assign a new label (with the policy's
+approval of course) using the **libselinux** API functions. The
+`process setexec`, `process setkeycreate` and `process setsockcreate`
+access vectors can be used to allow subjects to label processes,
+kernel keyrings, and sockets programmatically using the
+***setexec**(3)*, ***setkeycreatecon**(3)* and
+***setsockcreatecon**(3)* functions respectively, overriding
+transition statements.
+
+The `kernel` **initial security identifier** is used to associate
+a specified label with kernel objects, including kernel threads
+(both those that are created during initialization but also kernel
+threads created later), kernel-private sockets, synthetic objects
+representing kernel resources (e.g. the "system" class).
+
+It is true that processes created prior to initial policy load will
+also be in the kernel SID until/unless there is a policy loaded and
+either a policy-defined transition or an explicit setcon or
+setexeccon+execve, but that's just the typical default inheritance
+from creating task behavior for processes.
+
+The `unlabeled` **initial security identifier** is used
+to associate a specified label with subjects that had their label
+invalidated due to policy changes at runtime.
+
+It is also assigned as the initial state for various objects e.g.
+inodes, superblocks, etc until they reach a point where a more
+specific label can be determined e.g. from an xattr or from policy.
+The context associated with the unlabeled SID is used as the fallback
+context for both subjects and objects when their label is invalidated
+by a policy reload (their SID is unchanged but the SID is
+transparently remapped to the unlabeled context).
+
 ### Object Reuse
 
 As GNU / Linux runs it creates instances of objects and manages the
-- 
2.27.0

[SELinux-notebook PATCH v8] objects.md: some clarifications

[Dominick Grift]

Elaborate on labeling. Touch on the significance of the default statement, on various av permissions related to labeling using the libselinux API, and on how the kernel and unlabeled initial security identifiers are used to address labeling challenges in special cases such as initialization and failover respectively.

Signed-off-by: Dominick Grift <dominick.grift@defensec.nl>
---

v2: fixes patch description
v3: adding patch description, s/policies/policy's/, split unlabeled and kernel descriptions for clarity
v4: fixes another typo in description and emphasize system initialization a bit
v5: emphasize kernel threads with kernel isid description
v6: forgot to mention defaultuser, can only associate one label with isids
v7: copied and pasted feedback from Stephen Smalley
v8: missed a s/access vectors/permissions/ instance

 src/objects.md | 47 +++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 43 insertions(+), 4 deletions(-)

diff --git a/src/objects.md b/src/objects.md
index 58664ef..1907316 100644
--- a/src/objects.md
+++ b/src/objects.md
@@ -110,14 +110,20 @@ objects is managed by the system and generally unseen by the users
 (until labeling goes wrong !!). As processes and objects are created and
 destroyed, they either:
 
-1.  Inherit their labels from the parent process or object.
+1.  Inherit their labels from the parent process or object. The policy
+    default user, type, role and range statements can be used to
+	change the behavior as discussed in the [**Default Rules**](default_rules.md#default-object-rules)
+    section.
 2.  The policy type, role and range transition statements allow a
     different label to be assigned as discussed in the
     [**Domain and Object Transitions**](domain_object_transitions.md#domain-and-object-transitions)
     section.
-3.  SELinux-aware applications can enforce a new label (with the
-    policies approval of course) using the **libselinux** API
-    functions.
+3.  SELinux-aware applications can assign a new label (with the
+    policy's approval of course) using the **libselinux** API
+    functions. The `process setfscreate` permission can be used to
+    allow subjects to create files with a new label programmatically
+    using the ***setfscreatecon**(3)* function, overriding default
+    rules and transition statements.
 4.  An object manager (OM) can enforce a default label that can either
     be built into the OM or obtained via a configuration file (such as
     those used by
@@ -269,6 +275,39 @@ and manage their transition:
 
 `type_transition`, `role_transition` and `range_transition`
 
+SELinux-aware applications can assign a new label (with the policy's
+approval of course) using the **libselinux** API functions. The
+`process setexec`, `process setkeycreate` and `process setsockcreate`
+permissions can be used to allow subjects to label processes,
+kernel keyrings, and sockets programmatically using the
+***setexec**(3)*, ***setkeycreatecon**(3)* and
+***setsockcreatecon**(3)* functions respectively, overriding
+transition statements.
+
+The `kernel` **initial security identifier** is used to associate
+a specified label with kernel objects, including kernel threads
+(both those that are created during initialization but also kernel
+threads created later), kernel-private sockets, synthetic objects
+representing kernel resources (e.g. the "system" class).
+
+It is true that processes created prior to initial policy load will
+also be in the kernel SID until/unless there is a policy loaded and
+either a policy-defined transition or an explicit setcon or
+setexeccon+execve, but that's just the typical default inheritance
+from creating task behavior for processes.
+
+The `unlabeled` **initial security identifier** is used
+to associate a specified label with subjects that had their label
+invalidated due to policy changes at runtime.
+
+It is also assigned as the initial state for various objects e.g.
+inodes, superblocks, etc until they reach a point where a more
+specific label can be determined e.g. from an xattr or from policy.
+The context associated with the unlabeled SID is used as the fallback
+context for both subjects and objects when their label is invalidated
+by a policy reload (their SID is unchanged but the SID is
+transparently remapped to the unlabeled context).
+
 ### Object Reuse
 
 As GNU / Linux runs it creates instances of objects and manages the
-- 
2.27.0

Re: [SELinux-notebook PATCH v8] objects.md: some clarifications

[Dominick Grift]

Dominick Grift <dominick.grift@defensec.nl> writes:

> Elaborate on labeling. Touch on the significance of the default statement, on various av permissions related to labeling using the libselinux API, and on how the kernel and unlabeled initial security identifiers are used to address labeling challenges in special cases such as initialization and failover respectively.
>
> Signed-off-by: Dominick Grift <dominick.grift@defensec.nl>
> ---
>
> v2: fixes patch description
> v3: adding patch description, s/policies/policy's/, split unlabeled and kernel descriptions for clarity
> v4: fixes another typo in description and emphasize system initialization a bit
> v5: emphasize kernel threads with kernel isid description
> v6: forgot to mention defaultuser, can only associate one label with isids
> v7: copied and pasted feedback from Stephen Smalley
> v8: missed a s/access vectors/permissions/ instance
>
>  src/objects.md | 47 +++++++++++++++++++++++++++++++++++++++++++----
>  1 file changed, 43 insertions(+), 4 deletions(-)
>
> diff --git a/src/objects.md b/src/objects.md
> index 58664ef..1907316 100644
> --- a/src/objects.md
> +++ b/src/objects.md
> @@ -110,14 +110,20 @@ objects is managed by the system and generally unseen by the users
>  (until labeling goes wrong !!). As processes and objects are created and
>  destroyed, they either:
>  
> -1.  Inherit their labels from the parent process or object.
> +1.  Inherit their labels from the parent process or object. The policy
> +    default user, type, role and range statements can be used to
> +	change the behavior as discussed in the [**Default Rules**](default_rules.md#default-object-rules)
> +    section.
>  2.  The policy type, role and range transition statements allow a
>      different label to be assigned as discussed in the
>      [**Domain and Object Transitions**](domain_object_transitions.md#domain-and-object-transitions)
>      section.
> -3.  SELinux-aware applications can enforce a new label (with the
> -    policies approval of course) using the **libselinux** API
> -    functions.
> +3.  SELinux-aware applications can assign a new label (with the
> +    policy's approval of course) using the **libselinux** API
> +    functions. The `process setfscreate` permission can be used to
> +    allow subjects to create files with a new label programmatically
> +    using the ***setfscreatecon**(3)* function, overriding default
> +    rules and transition statements.
>  4.  An object manager (OM) can enforce a default label that can either
>      be built into the OM or obtained via a configuration file (such as
>      those used by
> @@ -269,6 +275,39 @@ and manage their transition:
>  
>  `type_transition`, `role_transition` and `range_transition`
>  
> +SELinux-aware applications can assign a new label (with the policy's
> +approval of course) using the **libselinux** API functions. The
> +`process setexec`, `process setkeycreate` and `process setsockcreate`
> +permissions can be used to allow subjects to label processes,
> +kernel keyrings, and sockets programmatically using the
> +***setexec**(3)*, ***setkeycreatecon**(3)* and
> +***setsockcreatecon**(3)* functions respectively, overriding
> +transition statements.
> +
> +The `kernel` **initial security identifier** is used to associate
> +a specified label with kernel objects, including kernel threads
> +(both those that are created during initialization but also kernel
> +threads created later), kernel-private sockets, synthetic objects
> +representing kernel resources (e.g. the "system" class).
> +
> +It is true that processes created prior to initial policy load will
> +also be in the kernel SID until/unless there is a policy loaded and
> +either a policy-defined transition or an explicit setcon or
> +setexeccon+execve, but that's just the typical default inheritance
> +from creating task behavior for processes.
> +
> +The `unlabeled` **initial security identifier** is used
> +to associate a specified label with subjects that had their label
> +invalidated due to policy changes at runtime.
> +
> +It is also assigned as the initial state for various objects e.g.
> +inodes, superblocks, etc until they reach a point where a more
> +specific label can be determined e.g. from an xattr or from policy.
> +The context associated with the unlabeled SID is used as the fallback
> +context for both subjects and objects when their label is invalidated
> +by a policy reload (their SID is unchanged but the SID is
> +transparently remapped to the unlabeled context).

I will note here that I suspect there is currently something broken
with libselinux / unlabeled sids

libselinux consumers still use *invalidated* contexts associated with
inodes to compute access vectors.

for example rpm will not consistently work until the filesystems are
relabeled after a new policy is loaded that invalidates contexts
currently associated with /bin/sh (entrypoint for setfscreatecon to
"rpm_script_t")

systemd will not consistently work until the filesystems are relabeled
after a new policy loaded that invalidates contexts currently associated
with (i suspect) parent directories for socket activated sock files
(maybe setfscreatecon?)

> +
>  ### Object Reuse
>  
>  As GNU / Linux runs it creates instances of objects and manages the

-- 
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift

Re: [SELinux-notebook PATCH v8] objects.md: some clarifications

[Stephen Smalley]

On Tue, Jul 21, 2020 at 4:14 PM Dominick Grift
<dominick.grift@defensec.nl> wrote:
> > +context for both subjects and objects when their label is invalidated
> > +by a policy reload (their SID is unchanged but the SID is
> > +transparently remapped to the unlabeled context).
>
> I will note here that I suspect there is currently something broken
> with libselinux / unlabeled sids
>
> libselinux consumers still use *invalidated* contexts associated with
> inodes to compute access vectors.
>
> for example rpm will not consistently work until the filesystems are
> relabeled after a new policy is loaded that invalidates contexts
> currently associated with /bin/sh (entrypoint for setfscreatecon to
> "rpm_script_t")
>
> systemd will not consistently work until the filesystems are relabeled
> after a new policy loaded that invalidates contexts currently associated
> with (i suspect) parent directories for socket activated sock files
> (maybe setfscreatecon?)

That's because userspace doesn't pass SIDs to the kernel (they aren't
exported by the kernel); it passes security contexts, and the kernel
refuses to accept invalid contexts. So a context previously used by
userspace that is invalidated by a policy reload and then later passed
in again to a kernel interface will produce an error.  IIRC, the
security_get_initial_context() and avc_get_initial_sid() interfaces
were added to allow userspace object managers like SEPostgreSQL to get
the context associated with an initial SID like the unlabeled SID for
their own internal use/handling, but libselinux doesn't try to remap
like that internally and it wouldn't always know whether the context
was previously valid unless it maintained state on all calls.

Re: [SELinux-notebook PATCH v8] objects.md: some clarifications

[Dominick Grift]

On 7/22/20 6:48 PM, Stephen Smalley wrote:
> On Tue, Jul 21, 2020 at 4:14 PM Dominick Grift
> <dominick.grift@defensec.nl> wrote:
>>> +context for both subjects and objects when their label is invalidated
>>> +by a policy reload (their SID is unchanged but the SID is
>>> +transparently remapped to the unlabeled context).
>>
>> I will note here that I suspect there is currently something broken
>> with libselinux / unlabeled sids
>>
>> libselinux consumers still use *invalidated* contexts associated with
>> inodes to compute access vectors.
>>
>> for example rpm will not consistently work until the filesystems are
>> relabeled after a new policy is loaded that invalidates contexts
>> currently associated with /bin/sh (entrypoint for setfscreatecon to
>> "rpm_script_t")
>>
>> systemd will not consistently work until the filesystems are relabeled
>> after a new policy loaded that invalidates contexts currently associated
>> with (i suspect) parent directories for socket activated sock files
>> (maybe setfscreatecon?)
> 
> That's because userspace doesn't pass SIDs to the kernel (they aren't
> exported by the kernel); it passes security contexts, and the kernel
> refuses to accept invalid contexts. So a context previously used by
> userspace that is invalidated by a policy reload and then later passed
> in again to a kernel interface will produce an error.  IIRC, the

Can we not just assume that if that happens, that the kernel should just
treat the context as if it were the context of the unlabeled isid.

I mean that is what it boils down to anyway: everything always needs a
valid context. so might as well treat invalid contexts as unlabeled
isids? Not sure how "state" is relevant here as invalid is invalid.

Regardless, this current behavior makes things less robust. I wont
pretent that I am qualified to judge whether addressing this is
technically possible or not.

> security_get_initial_context() and avc_get_initial_sid() interfaces
> were added to allow userspace object managers like SEPostgreSQL to get
> the context associated with an initial SID like the unlabeled SID for
> their own internal use/handling, but libselinux doesn't try to remap
> like that internally and it wouldn't always know whether the context
> was previously valid unless it maintained state on all calls.
> 

Re: [SELinux-notebook PATCH v8] objects.md: some clarifications

[Stephen Smalley]

On Wed, Jul 22, 2020 at 12:57 PM Dominick Grift
<dominick.grift@defensec.nl> wrote:
> Can we not just assume that if that happens, that the kernel should just
> treat the context as if it were the context of the unlabeled isid.

No, because then a simple typo or other error in a context provided by
a user or application would end up being handled as the unlabeled
context instead of producing an error return that can be handled by
the application or user.

> I mean that is what it boils down to anyway: everything always needs a
> valid context. so might as well treat invalid contexts as unlabeled
> isids? Not sure how "state" is relevant here as invalid is invalid.

The state is whether the context was previously valid and used by the
application.

Re: [SELinux-notebook PATCH v8] objects.md: some clarifications

[Dominick Grift]

On 7/22/20 7:32 PM, Stephen Smalley wrote:
> On Wed, Jul 22, 2020 at 12:57 PM Dominick Grift
> <dominick.grift@defensec.nl> wrote:
>> Can we not just assume that if that happens, that the kernel should just
>> treat the context as if it were the context of the unlabeled isid.
> 
> No, because then a simple typo or other error in a context provided by
> a user or application would end up being handled as the unlabeled
> context instead of producing an error return that can be handled by
> the application or user.

So are you saying that it is up to the libselinux consumers to deal with
this? what do you suggest they do in these situations?

> 
>> I mean that is what it boils down to anyway: everything always needs a
>> valid context. so might as well treat invalid contexts as unlabeled
>> isids? Not sure how "state" is relevant here as invalid is invalid.
> 
> The state is whether the context was previously valid and used by the
> application.
> 

Re: [SELinux-notebook PATCH v8] objects.md: some clarifications

[Stephen Smalley]

On Thu, Jul 23, 2020 at 4:13 AM Dominick Grift
<dominick.grift@defensec.nl> wrote:
>
>
>
> On 7/22/20 7:32 PM, Stephen Smalley wrote:
> > On Wed, Jul 22, 2020 at 12:57 PM Dominick Grift
> > <dominick.grift@defensec.nl> wrote:
> >> Can we not just assume that if that happens, that the kernel should just
> >> treat the context as if it were the context of the unlabeled isid.
> >
> > No, because then a simple typo or other error in a context provided by
> > a user or application would end up being handled as the unlabeled
> > context instead of producing an error return that can be handled by
> > the application or user.
>
> So are you saying that it is up to the libselinux consumers to deal with
> this? what do you suggest they do in these situations?

libselinux cannot handle it in the general case.  If using the
userspace AVC and SIDs obtained via avc_context_to_sid(), then
libselinux could transparently re-map those to the unlabeled context
if they cease to be valid.  Otherwise, it is up to the callers to deal
with and the correct handling is application-specific.  SEPostgreSQL
does this for example:
https://github.com/postgres/postgres/blob/master/contrib/sepgsql/label.c#L460

However, I don't think that would help something like systemd; even if
you re-map the context to the unlabeled context, you aren't going to
get a useful result from security_compute_create() or similar to use
in labeling sockets, processes, files, etc.

Re: [SELinux-notebook PATCH v8] objects.md: some clarifications

[Dominick Grift]

On 7/23/20 2:22 PM, Stephen Smalley wrote:
> On Thu, Jul 23, 2020 at 4:13 AM Dominick Grift
> <dominick.grift@defensec.nl> wrote:
>>
>>
>>
>> On 7/22/20 7:32 PM, Stephen Smalley wrote:
>>> On Wed, Jul 22, 2020 at 12:57 PM Dominick Grift
>>> <dominick.grift@defensec.nl> wrote:
>>>> Can we not just assume that if that happens, that the kernel should just
>>>> treat the context as if it were the context of the unlabeled isid.
>>>
>>> No, because then a simple typo or other error in a context provided by
>>> a user or application would end up being handled as the unlabeled
>>> context instead of producing an error return that can be handled by
>>> the application or user.
>>
>> So are you saying that it is up to the libselinux consumers to deal with
>> this? what do you suggest they do in these situations?
> 
> libselinux cannot handle it in the general case.  If using the
> userspace AVC and SIDs obtained via avc_context_to_sid(), then
> libselinux could transparently re-map those to the unlabeled context
> if they cease to be valid.  Otherwise, it is up to the callers to deal
> with and the correct handling is application-specific.  SEPostgreSQL
> does this for example:
> https://github.com/postgres/postgres/blob/master/contrib/sepgsql/label.c#L460
> 
> However, I don't think that would help something like systemd; even if
> you re-map the context to the unlabeled context, you aren't going to
> get a useful result from security_compute_create() or similar to use
> in labeling sockets, processes, files, etc.>

I suppose systemd probably should not fail "hard" when getfilecon (or
whatever) fails and returns with "invalid argument", and it should then
just not use setfilecon rather than not create the object at all (as it
seems to be doing now)

Re: [SELinux-notebook PATCH v8] objects.md: some clarifications

[Stephen Smalley]

On Thu, Jul 23, 2020 at 9:04 AM Dominick Grift
<dominick.grift@defensec.nl> wrote:
>
>
>
> On 7/23/20 2:22 PM, Stephen Smalley wrote:
> > On Thu, Jul 23, 2020 at 4:13 AM Dominick Grift
> > <dominick.grift@defensec.nl> wrote:
> >>
> >>
> >>
> >> On 7/22/20 7:32 PM, Stephen Smalley wrote:
> >>> On Wed, Jul 22, 2020 at 12:57 PM Dominick Grift
> >>> <dominick.grift@defensec.nl> wrote:
> >>>> Can we not just assume that if that happens, that the kernel should just
> >>>> treat the context as if it were the context of the unlabeled isid.
> >>>
> >>> No, because then a simple typo or other error in a context provided by
> >>> a user or application would end up being handled as the unlabeled
> >>> context instead of producing an error return that can be handled by
> >>> the application or user.
> >>
> >> So are you saying that it is up to the libselinux consumers to deal with
> >> this? what do you suggest they do in these situations?
> >
> > libselinux cannot handle it in the general case.  If using the
> > userspace AVC and SIDs obtained via avc_context_to_sid(), then
> > libselinux could transparently re-map those to the unlabeled context
> > if they cease to be valid.  Otherwise, it is up to the callers to deal
> > with and the correct handling is application-specific.  SEPostgreSQL
> > does this for example:
> > https://github.com/postgres/postgres/blob/master/contrib/sepgsql/label.c#L460
> >
> > However, I don't think that would help something like systemd; even if
> > you re-map the context to the unlabeled context, you aren't going to
> > get a useful result from security_compute_create() or similar to use
> > in labeling sockets, processes, files, etc.>
>
> I suppose systemd probably should not fail "hard" when getfilecon (or
> whatever) fails and returns with "invalid argument", and it should then
> just not use setfilecon rather than not create the object at all (as it
> seems to be doing now)

There is a tension there with fail-closed versus fail-open and the
potential for a security vulnerability to arise if it proceeds.  Would
have to look at the specifics to evaluate how it should be handled.
Of course, in practice, one really shouldn't be removing contexts
while they are still in use (or else use aliases to preserve some
degree of compatibility).

Re: [SELinux-notebook PATCH v8] objects.md: some clarifications

[Dominick Grift]

On 7/23/20 3:24 PM, Stephen Smalley wrote:
> On Thu, Jul 23, 2020 at 9:04 AM Dominick Grift+
> <dominick.grift@defensec.nl> wrote:
>>
>>
>>
>> On 7/23/20 2:22 PM, Stephen Smalley wrote:
>>> On Thu, Jul 23, 2020 at 4:13 AM Dominick Grift
>>> <dominick.grift@defensec.nl> wrote:
>>>>
>>>>
>>>>
>>>> On 7/22/20 7:32 PM, Stephen Smalley wrote:
>>>>> On Wed, Jul 22, 2020 at 12:57 PM Dominick Grift
>>>>> <dominick.grift@defensec.nl> wrote:
>>>>>> Can we not just assume that if that happens, that the kernel should just
>>>>>> treat the context as if it were the context of the unlabeled isid.
>>>>>
>>>>> No, because then a simple typo or other error in a context provided by
>>>>> a user or application would end up being handled as the unlabeled
>>>>> context instead of producing an error return that can be handled by
>>>>> the application or user.
>>>>
>>>> So are you saying that it is up to the libselinux consumers to deal with
>>>> this? what do you suggest they do in these situations?
>>>
>>> libselinux cannot handle it in the general case.  If using the
>>> userspace AVC and SIDs obtained via avc_context_to_sid(), then
>>> libselinux could transparently re-map those to the unlabeled context
>>> if they cease to be valid.  Otherwise, it is up to the callers to deal
>>> with and the correct handling is application-specific.  SEPostgreSQL
>>> does this for example:
>>> https://github.com/postgres/postgres/blob/master/contrib/sepgsql/label.c#L460
>>>
>>> However, I don't think that would help something like systemd; even if
>>> you re-map the context to the unlabeled context, you aren't going to
>>> get a useful result from security_compute_create() or similar to use
>>> in labeling sockets, processes, files, etc.>
>>
>> I suppose systemd probably should not fail "hard" when getfilecon (or
>> whatever) fails and returns with "invalid argument", and it should then
>> just not use setfilecon rather than not create the object at all (as it
>> seems to be doing now)
> 
> There is a tension there with fail-closed versus fail-open and the
> potential for a security vulnerability to arise if it proceeds.  Would
> have to look at the specifics to evaluate how it should be handled.
> Of course, in practice, one really shouldn't be removing contexts
> while they are still in use (or else use aliases to preserve some
> degree of compatibility).
> 

Using aliases is not a practical solution IMHO (although I suppose it
could be useful temporary hack), and effectively "removing contexts
while they are still in use" will alway's be the case in the current
state (even autorelabel will effectively generally run when the
filesystem has invalid labels, because that is the whole purpose of the app)

Maybe we should should rethink that whole autorelabel concept. Do we
really have to re-initialize filesystems in order to enable labeling
support? Should I be able to load a different policy at runtime, then
add a fsuse xattr rule, and be able to relabel at runtime without a
reboot, or without somehow re-initializing the filesystem?

Re: [SELinux-notebook PATCH v8] objects.md: some clarifications

[Dominick Grift]

On 7/23/20 3:24 PM, Stephen Smalley wrote:
> On Thu, Jul 23, 2020 at 9:04 AM Dominick Grift
> <dominick.grift@defensec.nl> wrote:
>>
>>+++
>>
>> On 7/23/20 2:22 PM, Stephen Smalley wrote:
>>> On Thu, Jul 23, 2020 at 4:13 AM Dominick Grift
>>> <dominick.grift@defensec.nl> wrote:
>>>>
>>>>
>>>>
>>>> On 7/22/20 7:32 PM, Stephen Smalley wrote:
>>>>> On Wed, Jul 22, 2020 at 12:57 PM Dominick Grift
>>>>> <dominick.grift@defensec.nl> wrote:
>>>>>> Can we not just assume that if that happens, that the kernel should just
>>>>>> treat the context as if it were the context of the unlabeled isid.
>>>>>
>>>>> No, because then a simple typo or other error in a context provided by
>>>>> a user or application would end up being handled as the unlabeled
>>>>> context instead of producing an error return that can be handled by
>>>>> the application or user.
>>>>
>>>> So are you saying that it is up to the libselinux consumers to deal with
>>>> this? what do you suggest they do in these situations?
>>>
>>> libselinux cannot handle it in the general case.  If using the
>>> userspace AVC and SIDs obtained via avc_context_to_sid(), then
>>> libselinux could transparently re-map those to the unlabeled context
>>> if they cease to be valid.  Otherwise, it is up to the callers to deal
>>> with and the correct handling is application-specific.  SEPostgreSQL
>>> does this for example:
>>> https://github.com/postgres/postgres/blob/master/contrib/sepgsql/label.c#L460
>>>
>>> However, I don't think that would help something like systemd; even if
>>> you re-map the context to the unlabeled context, you aren't going to
>>> get a useful result from security_compute_create() or similar to use
>>> in labeling sockets, processes, files, etc.>
>>
>> I suppose systemd probably should not fail "hard" when getfilecon (or
>> whatever) fails and returns with "invalid argument", and it should then
>> just not use setfilecon rather than not create the object at all (as it
>> seems to be doing now)
> 
> There is a tension there with fail-closed versus fail-open and the
> potential for a security vulnerability to arise if it proceeds.  Would
> have to look at the specifics to evaluate how it should be handled.
> Of course, in practice, one really shouldn't be removing contexts
> while they are still in use (or else use aliases to preserve some
> degree of compatibility).
> 

I guess if there is tension be between GNU/Linux use of libselinux and
SEAndroids use of libselinux, where SE for Android is implemented by the
vendor to be immutable by the device owner, and where GNU/Linux
leverages SELinux to empower device owners, then any tension can be
alleviated if Google forks libselinux. In GNU/Linux it should just be
possible to switch policies.

Re: [SELinux-notebook PATCH v8] objects.md: some clarifications

[Stephen Smalley]

On Fri, Jul 24, 2020 at 3:54 AM Dominick Grift
<dominick.grift@defensec.nl> wrote:
>
>
>
> On 7/23/20 3:24 PM, Stephen Smalley wrote:
>  > There is a tension there with fail-closed versus fail-open and the
> > potential for a security vulnerability to arise if it proceeds.  Would
> > have to look at the specifics to evaluate how it should be handled.
> > Of course, in practice, one really shouldn't be removing contexts
> > while they are still in use (or else use aliases to preserve some
> > degree of compatibility).
> >
>
> I guess if there is tension be between GNU/Linux use of libselinux and
> SEAndroids use of libselinux, where SE for Android is implemented by the
> vendor to be immutable by the device owner, and where GNU/Linux
> leverages SELinux to empower device owners, then any tension can be
> alleviated if Google forks libselinux. In GNU/Linux it should just be
> possible to switch policies.

I wasn't talking about Android, just about the tension of
fail-closed/secure versus fail-open/insecure in general.
I don't have any problem with someone installing a new policy that
completely changes the set of file contexts; I just don't think they
should do that at runtime without a reboot in between and expect
things to work seamlessly.

Re: [SELinux-notebook PATCH v8] objects.md: some clarifications

[Dominick Grift]

On 7/24/20 2:23 PM, Stephen Smalley wrote:
> On Fri, Jul 24, 2020 at 3:54 AM Dominick Grift
> <dominick.grift@defensec.nl> wrote:
>>
>>
>>
>> On 7/23/20 3:24 PM, Stephen Smalley wrote:
>>  > There is a tension there with fail-closed versus fail-open and the
>>> potential for a security vulnerability to arise if it proceeds.  Would
>>> have to look at the specifics to evaluate how it should be handled.
>>> Of course, in practice, one really shouldn't be removing contexts
>>> while they are still in use (or else use aliases to preserve some
>>> degree of compatibility).
>>>
>>
>> I guess if there is tension be between GNU/Linux use of libselinux and
>> SEAndroids use of libselinux, where SE for Android is implemented by the
>> vendor to be immutable by the device owner, and where GNU/Linux
>> leverages SELinux to empower device owners, then any tension can be
>> alleviated if Google forks libselinux. In GNU/Linux it should just be
>> possible to switch policies.
> 
> I wasn't talking about Android, just about the tension of
> fail-closed/secure versus fail-open/insecure in general.
> I don't have any problem with someone installing a new policy that
> completely changes the set of file contexts; I just don't think they
> should do that at runtime without a reboot in between and expect
> things to work seamlessly.
> 

Yes but that is not what I am saying. It does not work even when you
reboot. I tried to explain that:

You install a new policy and run fixfiles -F onboot && reboot (as one
should)

systemd will fail to compute create socket activated sockets. and so
these socket activated daemon fail to start.

One of the daemons is device-mapper, and so if you use LVM type stuff
you may end up with with a system that is only partially relabeled.

Not to mention that in the relabel target various other services that
are socket activated fail to start, and so  who know how else that may
affect things.

There is also this (however this might no longer be accurate):

systemd computes whether it can dynamically transition on boot. If the
systemd executable file has an invalid label and this computation fails
then systemd might just freeze in the first place.

Re: [SELinux-notebook PATCH v8] objects.md: some clarifications

[Stephen Smalley]

On Fri, Jul 24, 2020 at 8:29 AM Dominick Grift
<dominick.grift@defensec.nl> wrote:
>
>
>
> On 7/24/20 2:23 PM, Stephen Smalley wrote:
> > On Fri, Jul 24, 2020 at 3:54 AM Dominick Grift
> > <dominick.grift@defensec.nl> wrote:
> >>
> >>
> >>
> >> On 7/23/20 3:24 PM, Stephen Smalley wrote:
> >>  > There is a tension there with fail-closed versus fail-open and the
> >>> potential for a security vulnerability to arise if it proceeds.  Would
> >>> have to look at the specifics to evaluate how it should be handled.
> >>> Of course, in practice, one really shouldn't be removing contexts
> >>> while they are still in use (or else use aliases to preserve some
> >>> degree of compatibility).
> >>>
> >>
> >> I guess if there is tension be between GNU/Linux use of libselinux and
> >> SEAndroids use of libselinux, where SE for Android is implemented by the
> >> vendor to be immutable by the device owner, and where GNU/Linux
> >> leverages SELinux to empower device owners, then any tension can be
> >> alleviated if Google forks libselinux. In GNU/Linux it should just be
> >> possible to switch policies.
> >
> > I wasn't talking about Android, just about the tension of
> > fail-closed/secure versus fail-open/insecure in general.
> > I don't have any problem with someone installing a new policy that
> > completely changes the set of file contexts; I just don't think they
> > should do that at runtime without a reboot in between and expect
> > things to work seamlessly.
> >
>
> Yes but that is not what I am saying. It does not work even when you
> reboot. I tried to explain that:
>
> You install a new policy and run fixfiles -F onboot && reboot (as one
> should)
>
> systemd will fail to compute create socket activated sockets. and so
> these socket activated daemon fail to start.
>
> One of the daemons is device-mapper, and so if you use LVM type stuff
> you may end up with with a system that is only partially relabeled.
>
> Not to mention that in the relabel target various other services that
> are socket activated fail to start, and so  who know how else that may
> affect things.
>
> There is also this (however this might no longer be accurate):
>
> systemd computes whether it can dynamically transition on boot. If the
> systemd executable file has an invalid label and this computation fails
> then systemd might just freeze in the first place.

I think for this kind of complete policy changeover, you need to
relabel prior to rebooting.  Obviously that carries its own set of
challenges; you'd at least have to switch to permissive mode first and
potentially run setfiles in a domain (e.g. setfiles_mac_t) that is
allowed to get/set contexts unknown to the current policy
(CAP_MAC_ADMIN + capability2 mac_admin permission) or load the new
policy prior to running setfiles.  Or boot with SELinux disabled,
label via setfiles, and then boot with the new policy.  The preferred
model of course is to install with the desired policy in the first
place. IIUC Android upgrades are a bit different in that they reboot
into recovery mode, create the new filesystem (required anyway for
dm-verity) with the correct labels for its policy, and then reboot
into normal mode.

I don't think the separate autorelabel service can work for whole
policy changeovers; it would need to be done directly by systemd
itself prior to any other actions.  I think Android's init does
something like that for the userdata partition since that doesn't get
replaced on upgrades.

Re: [SELinux-notebook PATCH v8] objects.md: some clarifications

[Dominick Grift]

On 7/24/20 2:56 PM, Stephen Smalley wrote:
> On Fri, Jul 24, 2020 at 8:29 AM Dominick Grift
> <dominick.grift@defensec.nl> wrote:
>>
>>
>>
>> On 7/24/20 2:23 PM, Stephen Smalley wrote:
>>> On Fri, Jul 24, 2020 at 3:54 AM Dominick Grift
>>> <dominick.grift@defensec.nl> wrote:
>>>>
>>>>
>>>>
>>>> On 7/23/20 3:24 PM, Stephen Smalley wrote:
>>>>  > There is a tension there with fail-closed versus fail-open and the
>>>>> potential for a security vulnerability to arise if it proceeds.  Would
>>>>> have to look at the specifics to evaluate how it should be handled.
>>>>> Of course, in practice, one really shouldn't be removing contexts
>>>>> while they are still in use (or else use aliases to preserve some
>>>>> degree of compatibility).
>>>>>
>>>>
>>>> I guess if there is tension be between GNU/Linux use of libselinux and
>>>> SEAndroids use of libselinux, where SE for Android is implemented by the
>>>> vendor to be immutable by the device owner, and where GNU/Linux
>>>> leverages SELinux to empower device owners, then any tension can be
>>>> alleviated if Google forks libselinux. In GNU/Linux it should just be
>>>> possible to switch policies.
>>>
>>> I wasn't talking about Android, just about the tension of
>>> fail-closed/secure versus fail-open/insecure in general.
>>> I don't have any problem with someone installing a new policy that
>>> completely changes the set of file contexts; I just don't think they
>>> should do that at runtime without a reboot in between and expect
>>> things to work seamlessly.
>>>
>>
>> Yes but that is not what I am saying. It does not work even when you
>> reboot. I tried to explain that:
>>
>> You install a new policy and run fixfiles -F onboot && reboot (as one
>> should)
>>
>> systemd will fail to compute create socket activated sockets. and so
>> these socket activated daemon fail to start.
>>
>> One of the daemons is device-mapper, and so if you use LVM type stuff
>> you may end up with with a system that is only partially relabeled.
>>
>> Not to mention that in the relabel target various other services that
>> are socket activated fail to start, and so  who know how else that may
>> affect things.
>>
>> There is also this (however this might no longer be accurate):
>>
>> systemd computes whether it can dynamically transition on boot. If the
>> systemd executable file has an invalid label and this computation fails
>> then systemd might just freeze in the first place.
> 
> I think for this kind of complete policy changeover, you need to
> relabel prior to rebooting.

I think i tried that, but the extended attribute filesystems need to be
re-initialized AFAIK else fixfiles just returns with "Operation not
supported". Not sure if that strictly speaking requires a reboot or if
you can somehow do that with mount -o remount?

Is there a way to enable labeling support of extended attribute
filesystems without rebooting?

I think there was a patch recently by the Red Hat ContainerOS people to
enable labeling from the initramfs (ie labeling when SELinux is
disabled) How does that relate to the issue where I am seemingly not
able to relabel the filesystem after adding a fsuse trans rule without
rebooting? (ie SELinux is enabled, there is a fsuse xattr but the
filesystem hasnt been re-initialized yes and setfiles reports "operation
not supported")

  Obviously that carries its own set of
> challenges; you'd at least have to switch to permissive mode first and
> potentially run setfiles in a domain (e.g. setfiles_mac_t) that is
> allowed to get/set contexts unknown to the current policy
> (CAP_MAC_ADMIN + capability2 mac_admin permission) or load the new
> policy prior to running setfiles.  Or boot with SELinux disabled,
> label via setfiles, and then boot with the new policy.  The preferred
> model of course is to install with the desired policy in the first
> place. IIUC Android upgrades are a bit different in that they reboot
> into recovery mode, create the new filesystem (required anyway for
> dm-verity) with the correct labels for its policy, and then reboot
> into normal mode.
> 
> I don't think the separate autorelabel service can work for whole
> policy changeovers; it would need to be done directly by systemd
> itself prior to any other actions.  I think Android's init does
> something like that for the userdata partition since that doesn't get
> replaced on upgrades.
> 

Re: [SELinux-notebook PATCH v8] objects.md: some clarifications

[Stephen Smalley]

On Fri, Jul 24, 2020 at 9:06 AM Dominick Grift
<dominick.grift@defensec.nl> wrote:
>
>
>
> On 7/24/20 2:56 PM, Stephen Smalley wrote:
> > On Fri, Jul 24, 2020 at 8:29 AM Dominick Grift
> > <dominick.grift@defensec.nl> wrote:
> >>
> >>
> >>
> >> On 7/24/20 2:23 PM, Stephen Smalley wrote:
> >>> On Fri, Jul 24, 2020 at 3:54 AM Dominick Grift
> >>> <dominick.grift@defensec.nl> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 7/23/20 3:24 PM, Stephen Smalley wrote:
> > I think for this kind of complete policy changeover, you need to
> > relabel prior to rebooting.
>
> I think i tried that, but the extended attribute filesystems need to be
> re-initialized AFAIK else fixfiles just returns with "Operation not
> supported". Not sure if that strictly speaking requires a reboot or if
> you can somehow do that with mount -o remount?
>
> Is there a way to enable labeling support of extended attribute
> filesystems without rebooting?
>
> I think there was a patch recently by the Red Hat ContainerOS people to
> enable labeling from the initramfs (ie labeling when SELinux is
> disabled) How does that relate to the issue where I am seemingly not
> able to relabel the filesystem after adding a fsuse trans rule without
> rebooting? (ie SELinux is enabled, there is a fsuse xattr but the
> filesystem hasnt been re-initialized yes and setfiles reports "operation
> not supported")

So, first, fs_use_* rules should be relatively standard across SELinux
policies because they are more about the characteristics of the
filesystem driver and what it supports than about a particular policy.
The only thing policy-specific about them is the context to assign to
filesystem/superblock.  I updated scripts/selinux/mdp to auto-generate
appropriate fs_use* rules for many filesystem types and I'd recommend
using those rules in any new policy.  Similarly, mdp can be used as a
guide to which filesystem types should be using genfscon although
incomplete.  If there was a good general way that I could test for the
properties of a filesystem type in the SELinux module code and
automatically assign FS_USE_* and/or use of genfscon, I'd do that
instead.

Second, if your policy is changing these rules and the superblock has
already been initialized, then the only way to get your new rule
applied is if you can cause the old superblock to go away, e.g.
unmount.  And that won't work while it is in use.  So rebooting if
your only option if you cannot do that.  Rebooting with SELinux
disabled and then running setfiles will be the safest when performing
a complete policy changeover since you will then have no interference
by the old policy.

Re: [SELinux-notebook PATCH v8] objects.md: some clarifications

[Dominick Grift]

On 7/24/20 3:26 PM, Stephen Smalley wrote:
<snip>

> 
> Second, if your policy is changing these rules and the superblock has
> already been initialized, then the only way to get your new rule
> applied is if you can cause the old superblock to go away, e.g.
> unmount.  And that won't work while it is in use.  So rebooting if
> your only option if you cannot do that.  Rebooting with SELinux
> disabled and then running setfiles will be the safest when performing
> a complete policy changeover since you will then have no interference
> by the old policy.
> 

Thanks, I think this is the answer I was looking for. It is not entirely
elegant to say the least but I guess it will have to do.

Re: [SELinux-notebook PATCH v8] objects.md: some clarifications

[Dominick Grift]

On 7/22/20 6:48 PM, Stephen Smalley wrote:
> On Tue, Jul 21, 2020 at 4:14 PM Dominick Grift
> <dominick.grift@defensec.nl> wrote:
>>> +context for both subjects and objects when their label is invalidated
>>> +by a policy reload (their SID is unchanged but the SID is
>>> +transparently remapped to the unlabeled context).
>>
>> I will note here that I suspect there is currently something broken
>> with libselinux / unlabeled sids
>>
>> libselinux consumers still use *invalidated* contexts associated with
>> inodes to compute access vectors.
>>
>> for example rpm will not consistently work until the filesystems are
>> relabeled after a new policy is loaded that invalidates contexts
>> currently associated with /bin/sh (entrypoint for setfscreatecon to
>> "rpm_script_t")
>>
>> systemd will not consistently work until the filesystems are relabeled
>> after a new policy loaded that invalidates contexts currently associated
>> with (i suspect) parent directories for socket activated sock files
>> (maybe setfscreatecon?)
> 
> That's because userspace doesn't pass SIDs to the kernel (they aren't
> exported by the kernel); it passes security contexts, and the kernel
> refuses to accept invalid contexts. So a context previously used by
> userspace that is invalidated by a policy reload and then later passed
> in again to a kernel interface will produce an error.  IIRC, the
> security_get_initial_context() and avc_get_initial_sid() interfaces
> were added to allow userspace object managers like SEPostgreSQL to get
> the context associated with an initial SID like the unlabeled SID for
> their own internal use/handling, but libselinux doesn't try to remap
> like that internally and it wouldn't always know whether the context
> was previously valid unless it maintained state on all calls.
> 

This issue will also, in some cases, cause selinux-autorelabel to fail.


systemd can't compute the contexts for socket activated daemons, and so
these daemons fail to start. device mapper seems to be one of them, and
so partitions might not get mounted in the autorelabel target
effectively that means that autorelabel wont be able to relabel
everything (because its not mounted because device-mapper failed to
start, because systemd was unable to compute.

Re: [SELinux-notebook PATCH v8] objects.md: some clarifications

[Stephen Smalley]

On Tue, Jul 21, 2020 at 4:03 PM Dominick Grift
<dominick.grift@defensec.nl> wrote:
>
> Elaborate on labeling. Touch on the significance of the default statement, on various av permissions related to labeling using the libselinux API, and on how the kernel and unlabeled initial security identifiers are used to address labeling challenges in special cases such as initialization and failover respectively.
>
> Signed-off-by: Dominick Grift <dominick.grift@defensec.nl>
> ---

> diff --git a/src/objects.md b/src/objects.md
> index 58664ef..1907316 100644
> --- a/src/objects.md
> +++ b/src/objects.md
> @@ -269,6 +275,39 @@ and manage their transition:
> +The `kernel` **initial security identifier** is used to associate
> +a specified label with kernel objects, including kernel threads
> +(both those that are created during initialization but also kernel
> +threads created later), kernel-private sockets, synthetic objects

      ^^and^^

> +representing kernel resources (e.g. the "system" class).
> +
> +It is true that processes created prior to initial policy load will
> +also be in the kernel SID until/unless there is a policy loaded and
> +either a policy-defined transition or an explicit setcon or
> +setexeccon+execve, but that's just the typical default inheritance
> +from creating task behavior for processes.
> +
> +The `unlabeled` **initial security identifier** is used
> +to associate a specified label with subjects that had their label
> +invalidated due to policy changes at runtime.
> +
> +It is also assigned as the initial state for various objects e.g.
> +inodes, superblocks, etc until they reach a point where a more
> +specific label can be determined e.g. from an xattr or from policy.
> +The context associated with the unlabeled SID is used as the fallback
> +context for both subjects and objects when their label is invalidated
> +by a policy reload (their SID is unchanged but the SID is
> +transparently remapped to the unlabeled context).

There is some redundancy between the last sentence of the last
paragraph above and the preceding paragraph; the last sentence notes
that it is used for both subject and objects (not just subjects as in
the preceding paragraph) and that it is technically the context
associated with the unlabeled SID that is used for invalidated SIDs,
not the SID itself.  The unlabeled SID itself is used as per the 1st
sentence of the last paragraph above.

[SELinux-notebook PATCH v9] objects.md: some clarifications

[Dominick Grift]

Elaborate on labeling. Touch on the significance of the default statement, on various av permissions related to labeling using the libselinux API, and on how the kernel and unlabeled initial security identifiers are used to address labeling challenges in special cases such as initialization and failover respectively.

Signed-off-by: Dominick Grift <dominick.grift@defensec.nl>
---

v2: fixes patch description
v3: adding patch description, s/policies/policy's/, split unlabeled and kernel descriptions for clarity
v4: fixes another typo in description and emphasize system initialization a bit
v5: emphasize kernel threads with kernel isid description
v6: forgot to mention defaultuser, can only associate one label with isids
v7: copied and pasted feedback from Stephen Smalley
v8: missed a s/access vectors/permissions/ instance
v9: restructure unlabeled isid paragraph

 src/objects.md | 44 ++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 40 insertions(+), 4 deletions(-)

diff --git a/src/objects.md b/src/objects.md
index 58664ef..7e46b78 100644
--- a/src/objects.md
+++ b/src/objects.md
@@ -110,14 +110,20 @@ objects is managed by the system and generally unseen by the users
 (until labeling goes wrong !!). As processes and objects are created and
 destroyed, they either:
 
-1.  Inherit their labels from the parent process or object.
+1.  Inherit their labels from the parent process or object. The policy
+    default user, type, role and range statements can be used to
+	change the behavior as discussed in the [**Default Rules**](default_rules.md#default-object-rules)
+    section.
 2.  The policy type, role and range transition statements allow a
     different label to be assigned as discussed in the
     [**Domain and Object Transitions**](domain_object_transitions.md#domain-and-object-transitions)
     section.
-3.  SELinux-aware applications can enforce a new label (with the
-    policies approval of course) using the **libselinux** API
-    functions.
+3.  SELinux-aware applications can assign a new label (with the
+    policy's approval of course) using the **libselinux** API
+    functions. The `process setfscreate` permission can be used to
+    allow subjects to create files with a new label programmatically
+    using the ***setfscreatecon**(3)* function, overriding default
+    rules and transition statements.
 4.  An object manager (OM) can enforce a default label that can either
     be built into the OM or obtained via a configuration file (such as
     those used by
@@ -269,6 +275,36 @@ and manage their transition:
 
 `type_transition`, `role_transition` and `range_transition`
 
+SELinux-aware applications can assign a new label (with the policy's
+approval of course) using the **libselinux** API functions. The
+`process setexec`, `process setkeycreate` and `process setsockcreate`
+permissions can be used to allow subjects to label processes,
+kernel keyrings, and sockets programmatically using the
+***setexec**(3)*, ***setkeycreatecon**(3)* and
+***setsockcreatecon**(3)* functions respectively, overriding
+transition statements.
+
+The `kernel` **initial security identifier** is used to associate
+a specified label with kernel objects, including kernel threads
+(both those that are created during initialization but also kernel
+threads created later), kernel-private sockets and synthetic objects
+representing kernel resources (e.g. the "system" class).
+
+It is true that processes created prior to initial policy load will
+also be in the kernel SID until/unless there is a policy loaded and
+either a policy-defined transition or an explicit setcon or
+setexeccon+execve, but that's just the typical default inheritance
+from creating task behavior for processes.
+
+The context associated with the `unlabeled`
+**initial security identifier** is used as the fallback context for
+both subjects and objects when their label is invalidated by a policy
+reload (their SID is unchanged but the SID is transparently remapped
+to the unlabeled context). It is also assigned as the initial state
+for various objects e.g. inodes, superblocks, etc until they reach a
+point where a more specific label can be determined e.g. from an
+xattr or from policy. 
+
 ### Object Reuse
 
 As GNU / Linux runs it creates instances of objects and manages the
-- 
2.27.0

Re: [SELinux-notebook PATCH v9] objects.md: some clarifications

[Stephen Smalley]

On Thu, Jul 23, 2020 at 3:51 AM Dominick Grift
<dominick.grift@defensec.nl> wrote:
>
> Elaborate on labeling. Touch on the significance of the default statement, on various av permissions related to labeling using the libselinux API, and on how the kernel and unlabeled initial security identifiers are used to address labeling challenges in special cases such as initialization and failover respectively.
>
> Signed-off-by: Dominick Grift <dominick.grift@defensec.nl>

Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>

Re: [SELinux-notebook PATCH v9] objects.md: some clarifications

[Stephen Smalley]

On Thu, Jul 23, 2020 at 8:00 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Thu, Jul 23, 2020 at 3:51 AM Dominick Grift
> <dominick.grift@defensec.nl> wrote:
> >
> > Elaborate on labeling. Touch on the significance of the default statement, on various av permissions related to labeling using the libselinux API, and on how the kernel and unlabeled initial security identifiers are used to address labeling challenges in special cases such as initialization and failover respectively.
> >
> > Signed-off-by: Dominick Grift <dominick.grift@defensec.nl>
>
> Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>

Applied.

Re: [SELinux-notebook PATCH v9] objects.md: some clarifications

[Paul Moore]

On Mon, Jul 27, 2020 at 9:44 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Thu, Jul 23, 2020 at 8:00 AM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> >
> > On Thu, Jul 23, 2020 at 3:51 AM Dominick Grift
> > <dominick.grift@defensec.nl> wrote:
> > >
> > > Elaborate on labeling. Touch on the significance of the default statement, on various av permissions related to labeling using the libselinux API, and on how the kernel and unlabeled initial security identifiers are used to address labeling challenges in special cases such as initialization and failover respectively.
> > >
> > > Signed-off-by: Dominick Grift <dominick.grift@defensec.nl>
> >
> > Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
>
> Applied.

Thanks everyone.

-- 
paul moore
www.paul-moore.com