Re: pam_selinux and systemd

[Dominick Grift]

On Thu, Sep 07, 2017 at 04:30:36PM +0200, Dominick Grift wrote:
> On Thu, Sep 07, 2017 at 03:56:36PM +0200, Dominick Grift wrote:
> > On Thu, Sep 07, 2017 at 03:50:02PM +0200, Dominick Grift wrote:
> > > On Thu, Sep 07, 2017 at 03:30:47PM +0200, Dominick Grift wrote:
> > > > On Thu, Sep 07, 2017 at 03:22:42PM +0200, Dominick Grift wrote:
> > > > > On Thu, Sep 07, 2017 at 08:55:23AM -0400, Stephen Smalley wrote:
> > > > > > On Thu, 2017-09-07 at 11:05 +0200, Dominick Grift wrote:
> > > > > > > pam_selinux requirements are generally pretty simple: its used to
> > > > > > > associate a context with a login shell.
> > > > > > > 
> > > > > > > With systemd things have becomes a bit more complicated.
> > > > > > > 
> > > > > > > systemd uses pam_selinux to associate a context with both a login
> > > > > > > shell (via container-shell@.service) as well as with a systemd 
> > > > > > > --user 
> > > > > > > instance.
> > > > > > > 
> > > > > > > Ideally one would not associate a login shell context with a 
> > > > > > > systemd
> > > > > > > --user instance because a systemd --user instance needs 
> > > > > > > permissions
> > > > > > > that do not make sense for a login shell to have.
> > > > > > > 
> > > > > > > I am not aware of any way to make pam_selinux associate a context
> > > > > > > based on variable like for example: if its a login shell then
> > > > > > > associate this context , and if its a systemd --user instance then
> > > > > > > associate that context
> > > > > > > 
> > > > > > > This is an issue for me currently because if users are allowed to
> > > > > > > "host-shell" (machinectl shell .host) then they are able to open a
> > > > > > > shell with the context of the systemd --user instance and escape
> > > > > > > their shell restrictions
> > > > > > > 
> > > > > > > For now I can just block host-shell access with polkit but I am
> > > > > > > trying to figure out what it would take to address this challenge
> > > > > > > with pam_selinux
> > > > > > 
> > > > > > The logic for determining a security context from pam_selinux (using
> > > > > > libselinux get_ordered_context_with_level) can take the source/from
> > > > > > context (i.e. the context in which the caller of pam_selinux is 
> > > > > > running
> > > > > > ) into account as a factor in selecting which context to use, since 
> > > > > > it
> > > > > > checks reachability (transition permission) as part of
> > > > > > security_compute_user().  So that's a possible approach if you can
> > > > > > distinguish what contexts are reachable for systemd --user vs login
> > > > > > daemons.
> > > > > 
> > > > > The challenge here is that the source/from context is the same 
> > > > > whether systemd --system spawns a login shell on behalf of a login 
> > > > > user or whether systemd --system spawns a systemd --user instance on 
> > > > > behalf of a login user
> > > > > 
> > > > > > 
> > > > > > What SELinux permissions are required to host-shell?  Can you block
> > > > > > that via SELinux policy rather than just polkit?
> > > > > 
> > > > > Might be possible but probably tricky. Not sure what it would take.
> > > > > 
> > > > > machinectl shell can also be used to spawn a shell in a container and 
> > > > > this doesnt use pam_selinux, only machinectl shell .host makes 
> > > > > systemd --system use pam_selinux to determine the pam characteristics 
> > > > > to associate with the login shell on the host for the user
> > > > > 
> > > > > So "machinectl shell $container" makes machinectl itself a shell in 
> > > > > $container (no pam), and "machinectl shell .host" makes machinectl 
> > > > > tell systemd --system to spawn a login shell on the host (where 
> > > > > systemd --system is using pam_selinux)
> > > > > 
> > > > > > 
> > > > > > Running machinectl shell .host locally doesn't seem to work:
> > > > > > $ machinectl shell .host
> > > > > > Failed to get shell PTY: Access denied
> > > > > 
> > > > > Probably SELinux blocking then?
> > > > > 
> > > > > $ id -Z
> > > > > wheel.id:wheel.role:wheel.subj:s0
> > > > > $ machinectl shell .host
> > > > >  AUTHENTICATING FOR org.freedesktop.machine1.host-shell ===
> > > > > Authentication is required to acquire a shell on the local host.
> > > > > Authenticating as: kcinimod
> > > > > Password:
> > > > >  AUTHENTICATION COMPLETE ===
> > > > > Connected to the local host. Press ^] three times within 1s to exit 
> > > > > session
> > > > > # journalctl -rb
> > > > > sh: journalctl: command not found
> > > > > # bash
> > > > > # journalctl -rb | grep denied | head -n 1
> > > > > Sep 07 15:14:29 julius audit[1983]: AVC avc:  denied  { getattr } for 
> > > > >  pid=1983 comm="sh" path="/usr/bin/journalctl" dev="dm-1" ino=2756183 
> > > > > scontext=sysadm.id:sysadm.role:sysadm_systemd.subj:s0 
> > > > > tcontext=sys.id:sys.role:journalctl.cmd_file:s0 tclass=file 
> > > > > permissive=0
> > > > > # ps auxZ | grep sysadm_systemd.subj
> > > > > sysadm.id:sysadm.role:sysadm_systemd.subj:s0 root 

Re: [PATCH 1/6] libsepol: use IN6ADDR_ANY_INIT to initialize IPv6 addresses

[jwcart2]

On 09/03/2017 08:19 AM, Nicolas Iooss wrote:

When compiling libsepol with clang and some warning flags, the compiler
complains about the way IPv6 addresses are initialized:

 kernel_to_cil.c:2795:35: error: suggest braces around initialization
 of subobject [-Werror,-Wmissing-braces]
 struct in6_addr subnet_prefix = {0};
  ^
  {}

When replacing the initializer as suggested, gcc 4.8.4 complains:

 kernel_to_cil.c: In function ‘write_selinux_ibpkey_rules_to_cil’:
 kernel_to_cil.c:2795:9: error: missing initializer for field
 ‘__in6_u’ of ‘struct in6_addr’ [-Werror=missing-field-initializers]
   struct in6_addr subnet_prefix = {};
  ^

Thankfully netinet/in.h provides a macro to initialize struct in6_addr
variables:

 #define IN6ADDR_ANY_INIT { { { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 } } }

Both clang and gcc no longer report warnings when using this macro.

Signed-off-by: Nicolas Iooss 


This series has been applied.

Thanks,
Jim


---
  libsepol/src/kernel_to_cil.c  | 2 +-
  libsepol/src/kernel_to_conf.c | 2 +-
  libsepol/src/module_to_cil.c  | 2 +-
  3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/libsepol/src/kernel_to_cil.c b/libsepol/src/kernel_to_cil.c
index f1905a958ec0..0055c2386695 100644
--- a/libsepol/src/kernel_to_cil.c
+++ b/libsepol/src/kernel_to_cil.c
@@ -2788,7 +2788,7 @@ static int write_selinux_ibpkey_rules_to_cil(FILE *out, 
struct policydb *pdb)
  {
struct ocontext *ibpkeycon;
char subnet_prefix_str[INET6_ADDRSTRLEN];
-   struct in6_addr subnet_prefix = {0};
+   struct in6_addr subnet_prefix = IN6ADDR_ANY_INIT;
uint16_t low;
uint16_t high;
char low_high_str[44]; /* 2^64 <= 20 digits so "(low high)" <= 44 chars 
*/
diff --git a/libsepol/src/kernel_to_conf.c b/libsepol/src/kernel_to_conf.c
index a74873f01687..95aa92fc8c26 100644
--- a/libsepol/src/kernel_to_conf.c
+++ b/libsepol/src/kernel_to_conf.c
@@ -2649,7 +2649,7 @@ static int write_selinux_ibpkey_rules_to_conf(FILE *out, 
struct policydb *pdb)
  {
struct ocontext *ibpkeycon;
char subnet_prefix_str[INET6_ADDRSTRLEN];
-   struct in6_addr subnet_prefix = {0};
+   struct in6_addr subnet_prefix = IN6ADDR_ANY_INIT;
uint16_t low;
uint16_t high;
char low_high_str[44]; /* 2^64 <= 20 digits so "low-high" <= 44 chars */
diff --git a/libsepol/src/module_to_cil.c b/libsepol/src/module_to_cil.c
index 619a48f8c7b6..15b58a7aacee 100644
--- a/libsepol/src/module_to_cil.c
+++ b/libsepol/src/module_to_cil.c
@@ -2687,7 +2687,7 @@ static int ocontext_selinux_ibpkey_to_cil(struct policydb 
*pdb,
int rc = -1;
struct ocontext *ibpkeycon;
char subnet_prefix_str[INET6_ADDRSTRLEN];
-   struct in6_addr subnet_prefix = {0};
+   struct in6_addr subnet_prefix = IN6ADDR_ANY_INIT;
uint16_t high;
uint16_t low;
  




--
James Carter 
National Security Agency

Re: pam_selinux and systemd

[Dominick Grift]

On Thu, Sep 07, 2017 at 03:56:36PM +0200, Dominick Grift wrote:
> On Thu, Sep 07, 2017 at 03:50:02PM +0200, Dominick Grift wrote:
> > On Thu, Sep 07, 2017 at 03:30:47PM +0200, Dominick Grift wrote:
> > > On Thu, Sep 07, 2017 at 03:22:42PM +0200, Dominick Grift wrote:
> > > > On Thu, Sep 07, 2017 at 08:55:23AM -0400, Stephen Smalley wrote:
> > > > > On Thu, 2017-09-07 at 11:05 +0200, Dominick Grift wrote:
> > > > > > pam_selinux requirements are generally pretty simple: its used to
> > > > > > associate a context with a login shell.
> > > > > > 
> > > > > > With systemd things have becomes a bit more complicated.
> > > > > > 
> > > > > > systemd uses pam_selinux to associate a context with both a login
> > > > > > shell (via container-shell@.service) as well as with a systemd 
> > > > > > --user 
> > > > > > instance.
> > > > > > 
> > > > > > Ideally one would not associate a login shell context with a systemd
> > > > > > --user instance because a systemd --user instance needs permissions
> > > > > > that do not make sense for a login shell to have.
> > > > > > 
> > > > > > I am not aware of any way to make pam_selinux associate a context
> > > > > > based on variable like for example: if its a login shell then
> > > > > > associate this context , and if its a systemd --user instance then
> > > > > > associate that context
> > > > > > 
> > > > > > This is an issue for me currently because if users are allowed to
> > > > > > "host-shell" (machinectl shell .host) then they are able to open a
> > > > > > shell with the context of the systemd --user instance and escape
> > > > > > their shell restrictions
> > > > > > 
> > > > > > For now I can just block host-shell access with polkit but I am
> > > > > > trying to figure out what it would take to address this challenge
> > > > > > with pam_selinux
> > > > > 
> > > > > The logic for determining a security context from pam_selinux (using
> > > > > libselinux get_ordered_context_with_level) can take the source/from
> > > > > context (i.e. the context in which the caller of pam_selinux is 
> > > > > running
> > > > > ) into account as a factor in selecting which context to use, since it
> > > > > checks reachability (transition permission) as part of
> > > > > security_compute_user().  So that's a possible approach if you can
> > > > > distinguish what contexts are reachable for systemd --user vs login
> > > > > daemons.
> > > > 
> > > > The challenge here is that the source/from context is the same whether 
> > > > systemd --system spawns a login shell on behalf of a login user or 
> > > > whether systemd --system spawns a systemd --user instance on behalf of 
> > > > a login user
> > > > 
> > > > > 
> > > > > What SELinux permissions are required to host-shell?  Can you block
> > > > > that via SELinux policy rather than just polkit?
> > > > 
> > > > Might be possible but probably tricky. Not sure what it would take.
> > > > 
> > > > machinectl shell can also be used to spawn a shell in a container and 
> > > > this doesnt use pam_selinux, only machinectl shell .host makes systemd 
> > > > --system use pam_selinux to determine the pam characteristics to 
> > > > associate with the login shell on the host for the user
> > > > 
> > > > So "machinectl shell $container" makes machinectl itself a shell in 
> > > > $container (no pam), and "machinectl shell .host" makes machinectl tell 
> > > > systemd --system to spawn a login shell on the host (where systemd 
> > > > --system is using pam_selinux)
> > > > 
> > > > > 
> > > > > Running machinectl shell .host locally doesn't seem to work:
> > > > > $ machinectl shell .host
> > > > > Failed to get shell PTY: Access denied
> > > > 
> > > > Probably SELinux blocking then?
> > > > 
> > > > $ id -Z
> > > > wheel.id:wheel.role:wheel.subj:s0
> > > > $ machinectl shell .host
> > > >  AUTHENTICATING FOR org.freedesktop.machine1.host-shell ===
> > > > Authentication is required to acquire a shell on the local host.
> > > > Authenticating as: kcinimod
> > > > Password:
> > > >  AUTHENTICATION COMPLETE ===
> > > > Connected to the local host. Press ^] three times within 1s to exit 
> > > > session
> > > > # journalctl -rb
> > > > sh: journalctl: command not found
> > > > # bash
> > > > # journalctl -rb | grep denied | head -n 1
> > > > Sep 07 15:14:29 julius audit[1983]: AVC avc:  denied  { getattr } for  
> > > > pid=1983 comm="sh" path="/usr/bin/journalctl" dev="dm-1" ino=2756183 
> > > > scontext=sysadm.id:sysadm.role:sysadm_systemd.subj:s0 
> > > > tcontext=sys.id:sys.role:journalctl.cmd_file:s0 tclass=file permissive=0
> > > > # ps auxZ | grep sysadm_systemd.subj
> > > > sysadm.id:sysadm.role:sysadm_systemd.subj:s0 root 1983 0.2  0.0 14452 
> > > > 4500 pts/4 Ss 15:14   0:00 -bin/sh
> > > > sysadm.id:sysadm.role:sysadm_systemd.subj:s0 root 1988 0.2  0.0 82036 
> > > > 7956 ?   Ss   15:14   0:00 /usr/lib/systemd/systemd --user
> > > > 
> > > > So systemd --system runs -bin/sh using its pam_selinux which tells it 
> > 

Re: pam_selinux and systemd

[Dominick Grift]

On Thu, Sep 07, 2017 at 03:50:02PM +0200, Dominick Grift wrote:
> On Thu, Sep 07, 2017 at 03:30:47PM +0200, Dominick Grift wrote:
> > On Thu, Sep 07, 2017 at 03:22:42PM +0200, Dominick Grift wrote:
> > > On Thu, Sep 07, 2017 at 08:55:23AM -0400, Stephen Smalley wrote:
> > > > On Thu, 2017-09-07 at 11:05 +0200, Dominick Grift wrote:
> > > > > pam_selinux requirements are generally pretty simple: its used to
> > > > > associate a context with a login shell.
> > > > > 
> > > > > With systemd things have becomes a bit more complicated.
> > > > > 
> > > > > systemd uses pam_selinux to associate a context with both a login
> > > > > shell (via container-shell@.service) as well as with a systemd --user 
> > > > > instance.
> > > > > 
> > > > > Ideally one would not associate a login shell context with a systemd
> > > > > --user instance because a systemd --user instance needs permissions
> > > > > that do not make sense for a login shell to have.
> > > > > 
> > > > > I am not aware of any way to make pam_selinux associate a context
> > > > > based on variable like for example: if its a login shell then
> > > > > associate this context , and if its a systemd --user instance then
> > > > > associate that context
> > > > > 
> > > > > This is an issue for me currently because if users are allowed to
> > > > > "host-shell" (machinectl shell .host) then they are able to open a
> > > > > shell with the context of the systemd --user instance and escape
> > > > > their shell restrictions
> > > > > 
> > > > > For now I can just block host-shell access with polkit but I am
> > > > > trying to figure out what it would take to address this challenge
> > > > > with pam_selinux
> > > > 
> > > > The logic for determining a security context from pam_selinux (using
> > > > libselinux get_ordered_context_with_level) can take the source/from
> > > > context (i.e. the context in which the caller of pam_selinux is running
> > > > ) into account as a factor in selecting which context to use, since it
> > > > checks reachability (transition permission) as part of
> > > > security_compute_user().  So that's a possible approach if you can
> > > > distinguish what contexts are reachable for systemd --user vs login
> > > > daemons.
> > > 
> > > The challenge here is that the source/from context is the same whether 
> > > systemd --system spawns a login shell on behalf of a login user or 
> > > whether systemd --system spawns a systemd --user instance on behalf of a 
> > > login user
> > > 
> > > > 
> > > > What SELinux permissions are required to host-shell?  Can you block
> > > > that via SELinux policy rather than just polkit?
> > > 
> > > Might be possible but probably tricky. Not sure what it would take.
> > > 
> > > machinectl shell can also be used to spawn a shell in a container and 
> > > this doesnt use pam_selinux, only machinectl shell .host makes systemd 
> > > --system use pam_selinux to determine the pam characteristics to 
> > > associate with the login shell on the host for the user
> > > 
> > > So "machinectl shell $container" makes machinectl itself a shell in 
> > > $container (no pam), and "machinectl shell .host" makes machinectl tell 
> > > systemd --system to spawn a login shell on the host (where systemd 
> > > --system is using pam_selinux)
> > > 
> > > > 
> > > > Running machinectl shell .host locally doesn't seem to work:
> > > > $ machinectl shell .host
> > > > Failed to get shell PTY: Access denied
> > > 
> > > Probably SELinux blocking then?
> > > 
> > > $ id -Z
> > > wheel.id:wheel.role:wheel.subj:s0
> > > $ machinectl shell .host
> > >  AUTHENTICATING FOR org.freedesktop.machine1.host-shell ===
> > > Authentication is required to acquire a shell on the local host.
> > > Authenticating as: kcinimod
> > > Password:
> > >  AUTHENTICATION COMPLETE ===
> > > Connected to the local host. Press ^] three times within 1s to exit 
> > > session
> > > # journalctl -rb
> > > sh: journalctl: command not found
> > > # bash
> > > # journalctl -rb | grep denied | head -n 1
> > > Sep 07 15:14:29 julius audit[1983]: AVC avc:  denied  { getattr } for  
> > > pid=1983 comm="sh" path="/usr/bin/journalctl" dev="dm-1" ino=2756183 
> > > scontext=sysadm.id:sysadm.role:sysadm_systemd.subj:s0 
> > > tcontext=sys.id:sys.role:journalctl.cmd_file:s0 tclass=file permissive=0
> > > # ps auxZ | grep sysadm_systemd.subj
> > > sysadm.id:sysadm.role:sysadm_systemd.subj:s0 root 1983 0.2  0.0 14452 
> > > 4500 pts/4 Ss 15:14   0:00 -bin/sh
> > > sysadm.id:sysadm.role:sysadm_systemd.subj:s0 root 1988 0.2  0.0 82036 
> > > 7956 ?   Ss   15:14   0:00 /usr/lib/systemd/systemd --user
> > > 
> > > So systemd --system runs -bin/sh using its pam_selinux which tells it to 
> > > associate "sysadm_systemd.subj" with the login process, but that type is 
> > > for the systemd --user instance of this user
> > > then there is an automatic transition from sysadm_systemd.subj to 
> > > sysadm.subj on cmd.shell.cmd_file that eventually makes the 

Re: pam_selinux and systemd

[Dominick Grift]

On Thu, Sep 07, 2017 at 03:30:47PM +0200, Dominick Grift wrote:
> On Thu, Sep 07, 2017 at 03:22:42PM +0200, Dominick Grift wrote:
> > On Thu, Sep 07, 2017 at 08:55:23AM -0400, Stephen Smalley wrote:
> > > On Thu, 2017-09-07 at 11:05 +0200, Dominick Grift wrote:
> > > > pam_selinux requirements are generally pretty simple: its used to
> > > > associate a context with a login shell.
> > > > 
> > > > With systemd things have becomes a bit more complicated.
> > > > 
> > > > systemd uses pam_selinux to associate a context with both a login
> > > > shell (via container-shell@.service) as well as with a systemd --user 
> > > > instance.
> > > > 
> > > > Ideally one would not associate a login shell context with a systemd
> > > > --user instance because a systemd --user instance needs permissions
> > > > that do not make sense for a login shell to have.
> > > > 
> > > > I am not aware of any way to make pam_selinux associate a context
> > > > based on variable like for example: if its a login shell then
> > > > associate this context , and if its a systemd --user instance then
> > > > associate that context
> > > > 
> > > > This is an issue for me currently because if users are allowed to
> > > > "host-shell" (machinectl shell .host) then they are able to open a
> > > > shell with the context of the systemd --user instance and escape
> > > > their shell restrictions
> > > > 
> > > > For now I can just block host-shell access with polkit but I am
> > > > trying to figure out what it would take to address this challenge
> > > > with pam_selinux
> > > 
> > > The logic for determining a security context from pam_selinux (using
> > > libselinux get_ordered_context_with_level) can take the source/from
> > > context (i.e. the context in which the caller of pam_selinux is running
> > > ) into account as a factor in selecting which context to use, since it
> > > checks reachability (transition permission) as part of
> > > security_compute_user().  So that's a possible approach if you can
> > > distinguish what contexts are reachable for systemd --user vs login
> > > daemons.
> > 
> > The challenge here is that the source/from context is the same whether 
> > systemd --system spawns a login shell on behalf of a login user or whether 
> > systemd --system spawns a systemd --user instance on behalf of a login user
> > 
> > > 
> > > What SELinux permissions are required to host-shell?  Can you block
> > > that via SELinux policy rather than just polkit?
> > 
> > Might be possible but probably tricky. Not sure what it would take.
> > 
> > machinectl shell can also be used to spawn a shell in a container and this 
> > doesnt use pam_selinux, only machinectl shell .host makes systemd --system 
> > use pam_selinux to determine the pam characteristics to associate with the 
> > login shell on the host for the user
> > 
> > So "machinectl shell $container" makes machinectl itself a shell in 
> > $container (no pam), and "machinectl shell .host" makes machinectl tell 
> > systemd --system to spawn a login shell on the host (where systemd --system 
> > is using pam_selinux)
> > 
> > > 
> > > Running machinectl shell .host locally doesn't seem to work:
> > > $ machinectl shell .host
> > > Failed to get shell PTY: Access denied
> > 
> > Probably SELinux blocking then?
> > 
> > $ id -Z
> > wheel.id:wheel.role:wheel.subj:s0
> > $ machinectl shell .host
> >  AUTHENTICATING FOR org.freedesktop.machine1.host-shell ===
> > Authentication is required to acquire a shell on the local host.
> > Authenticating as: kcinimod
> > Password:
> >  AUTHENTICATION COMPLETE ===
> > Connected to the local host. Press ^] three times within 1s to exit session
> > # journalctl -rb
> > sh: journalctl: command not found
> > # bash
> > # journalctl -rb | grep denied | head -n 1
> > Sep 07 15:14:29 julius audit[1983]: AVC avc:  denied  { getattr } for  
> > pid=1983 comm="sh" path="/usr/bin/journalctl" dev="dm-1" ino=2756183 
> > scontext=sysadm.id:sysadm.role:sysadm_systemd.subj:s0 
> > tcontext=sys.id:sys.role:journalctl.cmd_file:s0 tclass=file permissive=0
> > # ps auxZ | grep sysadm_systemd.subj
> > sysadm.id:sysadm.role:sysadm_systemd.subj:s0 root 1983 0.2  0.0 14452 4500 
> > pts/4 Ss 15:14   0:00 -bin/sh
> > sysadm.id:sysadm.role:sysadm_systemd.subj:s0 root 1988 0.2  0.0 82036 7956 
> > ?   Ss   15:14   0:00 /usr/lib/systemd/systemd --user
> > 
> > So systemd --system runs -bin/sh using its pam_selinux which tells it to 
> > associate "sysadm_systemd.subj" with the login process, but that type is 
> > for the systemd --user instance of this user
> > then there is an automatic transition from sysadm_systemd.subj to 
> > sysadm.subj on cmd.shell.cmd_file that eventually makes the transition work 
> > when manually running bash
> > 
> > I put in that auto type transition (sysadm_systemd.subj > 
> > (cmd.shell.cmd_file) -> sysadm.subj) not realizing that the shell initially 
> > ends up with sysadm_systemd.subj via pam_selinux
> > 
> > So i should 

Re: pam_selinux and systemd

[Dominick Grift]

On Thu, Sep 07, 2017 at 03:22:42PM +0200, Dominick Grift wrote:
> On Thu, Sep 07, 2017 at 08:55:23AM -0400, Stephen Smalley wrote:
> > On Thu, 2017-09-07 at 11:05 +0200, Dominick Grift wrote:
> > > pam_selinux requirements are generally pretty simple: its used to
> > > associate a context with a login shell.
> > > 
> > > With systemd things have becomes a bit more complicated.
> > > 
> > > systemd uses pam_selinux to associate a context with both a login
> > > shell (via container-shell@.service) as well as with a systemd --user 
> > > instance.
> > > 
> > > Ideally one would not associate a login shell context with a systemd
> > > --user instance because a systemd --user instance needs permissions
> > > that do not make sense for a login shell to have.
> > > 
> > > I am not aware of any way to make pam_selinux associate a context
> > > based on variable like for example: if its a login shell then
> > > associate this context , and if its a systemd --user instance then
> > > associate that context
> > > 
> > > This is an issue for me currently because if users are allowed to
> > > "host-shell" (machinectl shell .host) then they are able to open a
> > > shell with the context of the systemd --user instance and escape
> > > their shell restrictions
> > > 
> > > For now I can just block host-shell access with polkit but I am
> > > trying to figure out what it would take to address this challenge
> > > with pam_selinux
> > 
> > The logic for determining a security context from pam_selinux (using
> > libselinux get_ordered_context_with_level) can take the source/from
> > context (i.e. the context in which the caller of pam_selinux is running
> > ) into account as a factor in selecting which context to use, since it
> > checks reachability (transition permission) as part of
> > security_compute_user().  So that's a possible approach if you can
> > distinguish what contexts are reachable for systemd --user vs login
> > daemons.
> 
> The challenge here is that the source/from context is the same whether 
> systemd --system spawns a login shell on behalf of a login user or whether 
> systemd --system spawns a systemd --user instance on behalf of a login user
> 
> > 
> > What SELinux permissions are required to host-shell?  Can you block
> > that via SELinux policy rather than just polkit?
> 
> Might be possible but probably tricky. Not sure what it would take.
> 
> machinectl shell can also be used to spawn a shell in a container and this 
> doesnt use pam_selinux, only machinectl shell .host makes systemd --system 
> use pam_selinux to determine the pam characteristics to associate with the 
> login shell on the host for the user
> 
> So "machinectl shell $container" makes machinectl itself a shell in 
> $container (no pam), and "machinectl shell .host" makes machinectl tell 
> systemd --system to spawn a login shell on the host (where systemd --system 
> is using pam_selinux)
> 
> > 
> > Running machinectl shell .host locally doesn't seem to work:
> > $ machinectl shell .host
> > Failed to get shell PTY: Access denied
> 
> Probably SELinux blocking then?
> 
> $ id -Z
> wheel.id:wheel.role:wheel.subj:s0
> $ machinectl shell .host
>  AUTHENTICATING FOR org.freedesktop.machine1.host-shell ===
> Authentication is required to acquire a shell on the local host.
> Authenticating as: kcinimod
> Password:
>  AUTHENTICATION COMPLETE ===
> Connected to the local host. Press ^] three times within 1s to exit session
> # journalctl -rb
> sh: journalctl: command not found
> # bash
> # journalctl -rb | grep denied | head -n 1
> Sep 07 15:14:29 julius audit[1983]: AVC avc:  denied  { getattr } for  
> pid=1983 comm="sh" path="/usr/bin/journalctl" dev="dm-1" ino=2756183 
> scontext=sysadm.id:sysadm.role:sysadm_systemd.subj:s0 
> tcontext=sys.id:sys.role:journalctl.cmd_file:s0 tclass=file permissive=0
> # ps auxZ | grep sysadm_systemd.subj
> sysadm.id:sysadm.role:sysadm_systemd.subj:s0 root 1983 0.2  0.0 14452 4500 
> pts/4 Ss 15:14   0:00 -bin/sh
> sysadm.id:sysadm.role:sysadm_systemd.subj:s0 root 1988 0.2  0.0 82036 7956 ?  
>  Ss   15:14   0:00 /usr/lib/systemd/systemd --user
> 
> So systemd --system runs -bin/sh using its pam_selinux which tells it to 
> associate "sysadm_systemd.subj" with the login process, but that type is for 
> the systemd --user instance of this user
> then there is an automatic transition from sysadm_systemd.subj to sysadm.subj 
> on cmd.shell.cmd_file that eventually makes the transition work when manually 
> running bash
> 
> I put in that auto type transition (sysadm_systemd.subj > 
> (cmd.shell.cmd_file) -> sysadm.subj) not realizing that the shell initially 
> ends up with sysadm_systemd.subj via pam_selinux
> 
> So i should remove that auto type transition as well since i shouldnt end up 
> in sysadm_systemd.subj in the first place

So to answer your question as to whether i would be able to block this access 
without polkit:

Yes i would be able to do this by just not allowing the systemd 

Re: pam_selinux and systemd

[Dominick Grift]

On Thu, Sep 07, 2017 at 08:55:23AM -0400, Stephen Smalley wrote:
> On Thu, 2017-09-07 at 11:05 +0200, Dominick Grift wrote:
> > pam_selinux requirements are generally pretty simple: its used to
> > associate a context with a login shell.
> > 
> > With systemd things have becomes a bit more complicated.
> > 
> > systemd uses pam_selinux to associate a context with both a login
> > shell (via container-shell@.service) as well as with a systemd --user 
> > instance.
> > 
> > Ideally one would not associate a login shell context with a systemd
> > --user instance because a systemd --user instance needs permissions
> > that do not make sense for a login shell to have.
> > 
> > I am not aware of any way to make pam_selinux associate a context
> > based on variable like for example: if its a login shell then
> > associate this context , and if its a systemd --user instance then
> > associate that context
> > 
> > This is an issue for me currently because if users are allowed to
> > "host-shell" (machinectl shell .host) then they are able to open a
> > shell with the context of the systemd --user instance and escape
> > their shell restrictions
> > 
> > For now I can just block host-shell access with polkit but I am
> > trying to figure out what it would take to address this challenge
> > with pam_selinux
> 
> The logic for determining a security context from pam_selinux (using
> libselinux get_ordered_context_with_level) can take the source/from
> context (i.e. the context in which the caller of pam_selinux is running
> ) into account as a factor in selecting which context to use, since it
> checks reachability (transition permission) as part of
> security_compute_user().  So that's a possible approach if you can
> distinguish what contexts are reachable for systemd --user vs login
> daemons.

The challenge here is that the source/from context is the same whether systemd 
--system spawns a login shell on behalf of a login user or whether systemd 
--system spawns a systemd --user instance on behalf of a login user

> 
> What SELinux permissions are required to host-shell?  Can you block
> that via SELinux policy rather than just polkit?

Might be possible but probably tricky. Not sure what it would take.

machinectl shell can also be used to spawn a shell in a container and this 
doesnt use pam_selinux, only machinectl shell .host makes systemd --system use 
pam_selinux to determine the pam characteristics to associate with the login 
shell on the host for the user

So "machinectl shell $container" makes machinectl itself a shell in $container 
(no pam), and "machinectl shell .host" makes machinectl tell systemd --system 
to spawn a login shell on the host (where systemd --system is using pam_selinux)

> 
> Running machinectl shell .host locally doesn't seem to work:
> $ machinectl shell .host
> Failed to get shell PTY: Access denied

Probably SELinux blocking then?

$ id -Z
wheel.id:wheel.role:wheel.subj:s0
$ machinectl shell .host
 AUTHENTICATING FOR org.freedesktop.machine1.host-shell ===
Authentication is required to acquire a shell on the local host.
Authenticating as: kcinimod
Password:
 AUTHENTICATION COMPLETE ===
Connected to the local host. Press ^] three times within 1s to exit session
# journalctl -rb
sh: journalctl: command not found
# bash
# journalctl -rb | grep denied | head -n 1
Sep 07 15:14:29 julius audit[1983]: AVC avc:  denied  { getattr } for  pid=1983 
comm="sh" path="/usr/bin/journalctl" dev="dm-1" ino=2756183 
scontext=sysadm.id:sysadm.role:sysadm_systemd.subj:s0 
tcontext=sys.id:sys.role:journalctl.cmd_file:s0 tclass=file permissive=0
# ps auxZ | grep sysadm_systemd.subj
sysadm.id:sysadm.role:sysadm_systemd.subj:s0 root 1983 0.2  0.0 14452 4500 
pts/4 Ss 15:14   0:00 -bin/sh
sysadm.id:sysadm.role:sysadm_systemd.subj:s0 root 1988 0.2  0.0 82036 7956 ?   
Ss   15:14   0:00 /usr/lib/systemd/systemd --user

So systemd --system runs -bin/sh using its pam_selinux which tells it to 
associate "sysadm_systemd.subj" with the login process, but that type is for 
the systemd --user instance of this user
then there is an automatic transition from sysadm_systemd.subj to sysadm.subj 
on cmd.shell.cmd_file that eventually makes the transition work when manually 
running bash

I put in that auto type transition (sysadm_systemd.subj > (cmd.shell.cmd_file) 
-> sysadm.subj) not realizing that the shell initially ends up with 
sysadm_systemd.subj via pam_selinux

So i should remove that auto type transition as well since i shouldnt end up in 
sysadm_systemd.subj in the first place

> 
> Ideally, I'd like to get rid of security_compute_user() entirely, take
> the logic for determining user context entirely to userspace, and
> simplify it significantly, both in libselinux and in pam_selinux. 
> That's been discussed previously on the list.
> 

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift

Re: conditional role and range transitions?

[Stephen Smalley]

On Thu, 2017-09-07 at 14:26 +0200, Dominick Grift wrote:
> I was just reminded of the fact that role and range transitions
> cannot be conditional in kernel policy.
> 
> Is this technically impossible? Why can type transitions be
> conditional in kernel policy but not role and range transitions?

It isn't a fundamental restriction, but the conditional policy
implementation was done entirely in terms of TE policy due to its
original use case and only (conditional) avtab entries can currently be
enabled/disabled based on boolean states.  So it should be possible to
implement conditional policy support for other kinds of transitions,
but not trivial.

Re: pam_selinux and systemd

[Stephen Smalley]

On Thu, 2017-09-07 at 11:05 +0200, Dominick Grift wrote:
> pam_selinux requirements are generally pretty simple: its used to
> associate a context with a login shell.
> 
> With systemd things have becomes a bit more complicated.
> 
> systemd uses pam_selinux to associate a context with both a login
> shell (via container-shell@.service) as well as with a systemd --user 
> instance.
> 
> Ideally one would not associate a login shell context with a systemd
> --user instance because a systemd --user instance needs permissions
> that do not make sense for a login shell to have.
> 
> I am not aware of any way to make pam_selinux associate a context
> based on variable like for example: if its a login shell then
> associate this context , and if its a systemd --user instance then
> associate that context
> 
> This is an issue for me currently because if users are allowed to
> "host-shell" (machinectl shell .host) then they are able to open a
> shell with the context of the systemd --user instance and escape
> their shell restrictions
> 
> For now I can just block host-shell access with polkit but I am
> trying to figure out what it would take to address this challenge
> with pam_selinux

The logic for determining a security context from pam_selinux (using
libselinux get_ordered_context_with_level) can take the source/from
context (i.e. the context in which the caller of pam_selinux is running
) into account as a factor in selecting which context to use, since it
checks reachability (transition permission) as part of
security_compute_user().  So that's a possible approach if you can
distinguish what contexts are reachable for systemd --user vs login
daemons.

What SELinux permissions are required to host-shell?  Can you block
that via SELinux policy rather than just polkit?

Running machinectl shell .host locally doesn't seem to work:
$ machinectl shell .host
Failed to get shell PTY: Access denied

Ideally, I'd like to get rid of security_compute_user() entirely, take
the logic for determining user context entirely to userspace, and
simplify it significantly, both in libselinux and in pam_selinux. 
That's been discussed previously on the list.

Re: [PATCH 1/3] security: bpf: Add eBPF LSM hooks to security module

[Stephen Smalley]

On Tue, 2017-09-05 at 15:24 -0700, Chenbo Feng via Selinux wrote:
> On Fri, Sep 1, 2017 at 5:50 AM, Stephen Smalley 
> wrote:
> > On Thu, 2017-08-31 at 13:56 -0700, Chenbo Feng wrote:
> > > From: Chenbo Feng 
> > > 
> > > Introduce 5 LSM hooks to provide finer granularity controls on
> > > eBPF
> > > related operations including create eBPF maps, modify and read
> > > eBPF
> > > maps
> > > content and load eBPF programs to the kernel. Hooks use the new
> > > security
> > > pointer inside the eBPF map struct to store the owner's security
> > > information and the different security modules can perform
> > > different
> > > checks based on the information stored inside the security field.
> > > 
> > > Signed-off-by: Chenbo Feng 
> > > ---
> > >  include/linux/lsm_hooks.h | 41
> > > +
> > >  include/linux/security.h  | 36
> > > 
> > >  security/security.c   | 28 
> > >  3 files changed, 105 insertions(+)
> > > 
> > > diff --git a/include/linux/lsm_hooks.h
> > > b/include/linux/lsm_hooks.h
> > > index ce02f76a6188..3aaf9a08a983 100644
> > > --- a/include/linux/lsm_hooks.h
> > > +++ b/include/linux/lsm_hooks.h
> > > @@ -1353,6 +1353,32 @@
> > >   *   @inode we wish to get the security context of.
> > >   *   @ctx is a pointer in which to place the allocated security
> > > context.
> > >   *   @ctxlen points to the place to put the length of @ctx.
> > > + *
> > > + * Security hooks for using the eBPF maps and programs
> > > functionalities through
> > > + * eBPF syscalls.
> > > + *
> > > + * @bpf_map_create:
> > > + *   Check permissions prior to creating a new bpf map.
> > > + *   Return 0 if the permission is granted.
> > > + *
> > > + * @bpf_map_modify:
> > > + *   Check permission prior to insert, update and delete map
> > > content.
> > > + *   @map pointer to the struct bpf_map that contains map
> > > information.
> > > + *   Return 0 if the permission is granted.
> > > + *
> > > + * @bpf_map_read:
> > > + *   Check permission prior to read a bpf map content.
> > > + *   @map pointer to the struct bpf_map that contains map
> > > information.
> > > + *   Return 0 if the permission is granted.
> > > + *
> > > + * @bpf_prog_load:
> > > + *   Check permission prior to load eBPF program.
> > > + *   Return 0 if the permission is granted.
> > > + *
> > > + * @bpf_post_create:
> > > + *   Initialize the bpf object security field inside struct
> > > bpf_maps and
> > > + *   it is used for future security checks.
> > > + *
> > >   */
> > >  union security_list_options {
> > >   int (*binder_set_context_mgr)(struct task_struct *mgr);
> > > @@ -1685,6 +1711,14 @@ union security_list_options {
> > >   struct audit_context *actx);
> > >   void (*audit_rule_free)(void *lsmrule);
> > >  #endif /* CONFIG_AUDIT */
> > > +
> > > +#ifdef CONFIG_BPF_SYSCALL
> > > + int (*bpf_map_create)(void);
> > > + int (*bpf_map_read)(struct bpf_map *map);
> > > + int (*bpf_map_modify)(struct bpf_map *map);
> > > + int (*bpf_prog_load)(void);
> > > + int (*bpf_post_create)(struct bpf_map *map);
> > > +#endif /* CONFIG_BPF_SYSCALL */
> > >  };
> > > 
> > >  struct security_hook_heads {
> > > @@ -1905,6 +1939,13 @@ struct security_hook_heads {
> > >   struct list_head audit_rule_match;
> > >   struct list_head audit_rule_free;
> > >  #endif /* CONFIG_AUDIT */
> > > +#ifdef CONFIG_BPF_SYSCALL
> > > + struct list_head bpf_map_create;
> > > + struct list_head bpf_map_read;
> > > + struct list_head bpf_map_modify;
> > > + struct list_head bpf_prog_load;
> > > + struct list_head bpf_post_create;
> > > +#endif /* CONFIG_BPF_SYSCALL */
> > >  } __randomize_layout;
> > > 
> > >  /*
> > > diff --git a/include/linux/security.h b/include/linux/security.h
> > > index 458e24bea2d4..0656a4f74d14 100644
> > > --- a/include/linux/security.h
> > > +++ b/include/linux/security.h
> > > @@ -31,6 +31,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > > 
> > >  struct linux_binprm;
> > >  struct cred;
> > > @@ -1735,6 +1736,41 @@ static inline void
> > > securityfs_remove(struct
> > > dentry *dentry)
> > > 
> > >  #endif
> > > 
> > > +#ifdef CONFIG_BPF_SYSCALL
> > > +#ifdef CONFIG_SECURITY
> > > +int security_map_create(void);
> > > +int security_map_modify(struct bpf_map *map);
> > > +int security_map_read(struct bpf_map *map);
> > > +int security_prog_load(void);
> > > +int security_post_create(struct bpf_map *map);
> > > +#else
> > > +static inline int security_map_create(void)
> > > +{
> > > + return 0;
> > > +}
> > > +
> > > +static inline int security_map_read(struct bpf_map *map)
> > > +{
> > > + return 0;
> > > +}
> > > +
> > > +static inline int security_map_modify(struct bpf_map *map)
> > > +{
> > > + return 0;
> > > +}
> > > +
> > > +static inline int 

conditional role and range transitions?

[Dominick Grift]

I was just reminded of the fact that role and range transitions cannot be 
conditional in kernel policy.

Is this technically impossible? Why can type transitions be conditional in 
kernel policy but not role and range transitions?

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift


signature.asc
Description: PGP signature

pam_selinux and systemd

[Dominick Grift]

pam_selinux requirements are generally pretty simple: its used to associate a 
context with a login shell.

With systemd things have becomes a bit more complicated.

systemd uses pam_selinux to associate a context with both a login shell (via 
container-shell@.service) as well as with a systemd --user instance.

Ideally one would not associate a login shell context with a systemd --user 
instance because a systemd --user instance needs permissions that do not make 
sense for a login shell to have.

I am not aware of any way to make pam_selinux associate a context based on 
variable like for example: if its a login shell then associate this context , 
and if its a systemd --user instance then associate that context

This is an issue for me currently because if users are allowed to "host-shell" 
(machinectl shell .host) then they are able to open a shell with the context of 
the systemd --user instance and escape their shell restrictions

For now I can just block host-shell access with polkit but I am trying to 
figure out what it would take to address this challenge with pam_selinux

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift


signature.asc
Description: PGP signature