run_init messes up terminal settings

run_init messes up terminal settings

[Laurent Bigonville]

[-- Attachment #1: Type: text/plain, Size: 1481 bytes --]

Hello,

Russell opened the following bug regarding run_init in the debian bts:

====

[...]
It turns out that the problem was not running $(arch), but running run_init in
the shell it spawned.  Below is an example of reproducing this, the first time
run_init performs as expected.  The second time is fails without me even
typing a password or pressing ENTER.  The result is the same with any command,
but ls is just a good example.  This happens no matter what shell is spawned
(whether it's ssh, su, or just an Xterm), run_init seems generally broken with
the 4.9.0-2-amd64/4.9.13-1 kernel at least.

NB I can't rule out the possibility of a kernel bug at this stage.  But at
this time it seems best to assume it's a run_init bug until proven otherwise.

Sorry for the inconvenience Andreas.

# run_init ls /boot
Authenticating root.
Password:
config-4.9.0-2-amd64      lost+found                System.map-4.9.0-3-amd64
config-4.9.0-3-amd64      memtest86+.bin            vmlinuz-4.9.0-2-amd64
grub                      memtest86+_multiboot.bin  vmlinuz-4.9.0-3-amd64
initrd.img-4.9.0-2-amd64  real
initrd.img-4.9.0-3-amd64  System.map-4.9.0-2-amd64
# run_init ls /boot
Authenticating root.
Password:
run_init: incorrect password for root
authentication failed.
#

====

I can reproduce this with 2.7-rc3, run_init is compiled with pam and 
audit support.

An idea what could happen here?

Regards,

Laurent Bigonville

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863187


[-- Attachment #2: Type: text/html, Size: 1918 bytes --]

Re: run_init messes up terminal settings

[Stephen Smalley]

On Sat, 2017-06-24 at 12:20 +0200, Laurent Bigonville wrote:
> Hello,
> Russell opened the following bug regarding run_init in the debian
> bts:
> ====
> [...]
> It turns out that the problem was not running $(arch), but running
> run_init in 
> the shell it spawned.  Below is an example of reproducing this, the
> first time 
> run_init performs as expected.  The second time is fails without me
> even 
> typing a password or pressing ENTER.  The result is the same with any
> command, 
> but ls is just a good example.  This happens no matter what shell is
> spawned 
> (whether it's ssh, su, or just an Xterm), run_init seems generally
> broken with 
> the 4.9.0-2-amd64/4.9.13-1 kernel at least.
> 
> NB I can't rule out the possibility of a kernel bug at this
> stage.  But at 
> this time it seems best to assume it's a run_init bug until proven
> otherwise.
> 
> Sorry for the inconvenience Andreas.
> 
> # run_init ls /boot
> Authenticating root.
> Password: 
> config-4.9.0-2-amd64      lost+found                System.map-4.9.0-
> 3-amd64
> config-4.9.0-3-amd64      memtest86+.bin            vmlinuz-4.9.0-2-
> amd64
> grub                      memtest86+_multiboot.bin  vmlinuz-4.9.0-3-
> amd64
> initrd.img-4.9.0-2-amd64  real
> initrd.img-4.9.0-3-amd64  System.map-4.9.0-2-amd64
> # run_init ls /boot
> Authenticating root.
> Password: 
> run_init: incorrect password for root
> authentication failed.
> # 
> ====
> I can reproduce this with 2.7-rc3, run_init is compiled with pam and
> audit support.
> An idea what could happen here?
> Regards,
> Laurent Bigonville
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863187

I don't think this could have ever worked under run_init since
open_init_pty was introduced (originally from Debian); note that
open_init_pty does alter terminal settings.

I don't quite follow the example given above.  It shows executing
run_init twice with ls /boot as the arguments, which is not running
run_init within run_init.  That works fine for me.

If I try something like:
run_init run_init ls /boot
which actually runs run_init within run_init, then that also works for
me without problem.

If I try something like:
run_init /bin/bash
then I lose any echoing of input characters to the shell (due to
open_init_pty turning it off), but I can enter commands and execute
them, or run stty sane to regain echoing.  But I don't think that has
ever been supported since the introduction of open_init_pty in 2005
(policycoreutils 1.21.2).  What's the use case for it?

Side bar: run_init (and open_init_pty) are no longer packaged by Fedora
since systemd renders it unnecessary, and even prior to that, Fedora
policy enabled DIRECT_INITRC=y in build.conf, and therefore run_init
wasn't required for typical operation (maybe under -mls policy it was
still needed, not sure). Possibly we should move run_init out of
policycoreutils into its own subdirectory in the selinux userspace tree
to reflect this transition and start deprecating it.

Re: run_init messes up terminal settings

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 3888 bytes --]

On Mon, Jun 26, 2017 at 09:08:16AM -0400, Stephen Smalley wrote:
> On Sat, 2017-06-24 at 12:20 +0200, Laurent Bigonville wrote:
> > Hello,
> > Russell opened the following bug regarding run_init in the debian
> > bts:
> > ====
> > [...]
> > It turns out that the problem was not running $(arch), but running
> > run_init in 
> > the shell it spawned.  Below is an example of reproducing this, the
> > first time 
> > run_init performs as expected.  The second time is fails without me
> > even 
> > typing a password or pressing ENTER.  The result is the same with any
> > command, 
> > but ls is just a good example.  This happens no matter what shell is
> > spawned 
> > (whether it's ssh, su, or just an Xterm), run_init seems generally
> > broken with 
> > the 4.9.0-2-amd64/4.9.13-1 kernel at least.
> > 
> > NB I can't rule out the possibility of a kernel bug at this
> > stage.  But at 
> > this time it seems best to assume it's a run_init bug until proven
> > otherwise.
> > 
> > Sorry for the inconvenience Andreas.
> > 
> > # run_init ls /boot
> > Authenticating root.
> > Password: 
> > config-4.9.0-2-amd64      lost+found                System.map-4.9.0-
> > 3-amd64
> > config-4.9.0-3-amd64      memtest86+.bin            vmlinuz-4.9.0-2-
> > amd64
> > grub                      memtest86+_multiboot.bin  vmlinuz-4.9.0-3-
> > amd64
> > initrd.img-4.9.0-2-amd64  real
> > initrd.img-4.9.0-3-amd64  System.map-4.9.0-2-amd64
> > # run_init ls /boot
> > Authenticating root.
> > Password: 
> > run_init: incorrect password for root
> > authentication failed.
> > # 
> > ====
> > I can reproduce this with 2.7-rc3, run_init is compiled with pam and
> > audit support.
> > An idea what could happen here?
> > Regards,
> > Laurent Bigonville
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863187
> 
> I don't think this could have ever worked under run_init since
> open_init_pty was introduced (originally from Debian); note that
> open_init_pty does alter terminal settings.
> 
> I don't quite follow the example given above.  It shows executing
> run_init twice with ls /boot as the arguments, which is not running
> run_init within run_init.  That works fine for me.
> 
> If I try something like:
> run_init run_init ls /boot
> which actually runs run_init within run_init, then that also works for
> me without problem.
> 
> If I try something like:
> run_init /bin/bash
> then I lose any echoing of input characters to the shell (due to
> open_init_pty turning it off), but I can enter commands and execute
> them, or run stty sane to regain echoing.  But I don't think that has
> ever been supported since the introduction of open_init_pty in 2005
> (policycoreutils 1.21.2).  What's the use case for it?
> 
> Side bar: run_init (and open_init_pty) are no longer packaged by Fedora
> since systemd renders it unnecessary, and even prior to that, Fedora
> policy enabled DIRECT_INITRC=y in build.conf, and therefore run_init

Correct me if i am wrong but fedora has DIRECT_INITRC=n AFAICT

https://src.fedoraproject.org/cgit/rpms/selinux-policy.git/tree/selinux-policy.spec#n173
https://src.fedoraproject.org/cgit/rpms/selinux-policy.git/tree/selinux-policy.spec#n393

I vaguely recall that in a strict environment one still might need run_init for the `update aliases` functionality in redhar-based distributions.. i might be wrong though

> wasn't required for typical operation (maybe under -mls policy it was
> still needed, not sure). Possibly we should move run_init out of
> policycoreutils into its own subdirectory in the selinux userspace tree
> to reflect this transition and start deprecating it.
> 

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: run_init messes up terminal settings

[Laurent Bigonville]

Le 26/06/17 à 15:08, Stephen Smalley a écrit :
> On Sat, 2017-06-24 at 12:20 +0200, Laurent Bigonville wrote:
>> Hello,
>> Russell opened the following bug regarding run_init in the debian
>> bts:
>> ====
>> [...]
>> It turns out that the problem was not running $(arch), but running
>> run_init in
>> the shell it spawned.  Below is an example of reproducing this, the
>> first time
>> run_init performs as expected.  The second time is fails without me
>> even
>> typing a password or pressing ENTER.  The result is the same with any
>> command,
>> but ls is just a good example.  This happens no matter what shell is
>> spawned
>> (whether it's ssh, su, or just an Xterm), run_init seems generally
>> broken with
>> the 4.9.0-2-amd64/4.9.13-1 kernel at least.
>>
>> NB I can't rule out the possibility of a kernel bug at this
>> stage.  But at
>> this time it seems best to assume it's a run_init bug until proven
>> otherwise.
>>
>> Sorry for the inconvenience Andreas.
>>
>> # run_init ls /boot
>> Authenticating root.
>> Password:
>> config-4.9.0-2-amd64      lost+found                System.map-4.9.0-
>> 3-amd64
>> config-4.9.0-3-amd64      memtest86+.bin            vmlinuz-4.9.0-2-
>> amd64
>> grub                      memtest86+_multiboot.bin  vmlinuz-4.9.0-3-
>> amd64
>> initrd.img-4.9.0-2-amd64  real
>> initrd.img-4.9.0-3-amd64  System.map-4.9.0-2-amd64
>> # run_init ls /boot
>> Authenticating root.
>> Password:
>> run_init: incorrect password for root
>> authentication failed.
>> #
>> ====
>> I can reproduce this with 2.7-rc3, run_init is compiled with pam and
>> audit support.
>> An idea what could happen here?
>> Regards,
>> Laurent Bigonville
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863187
> I don't think this could have ever worked under run_init since
> open_init_pty was introduced (originally from Debian); note that
> open_init_pty does alter terminal settings.
>
> I don't quite follow the example given above.  It shows executing
> run_init twice with ls /boot as the arguments, which is not running
> run_init within run_init.  That works fine for me.

I just re-tried again and I can definitely reproduce this in debian 
unstable. My complete test case is:

sudo -i
<type the password>
run_init ls /boot
<type the password>
<ls output>
run_init ls /boot
<error>

If I exit the shell started by sudo, run_init will works again for one 
invocation before getting the error again.

> If I try something like:
> run_init run_init ls /boot
> which actually runs run_init within run_init, then that also works for
> me without problem.
>
> If I try something like:
> run_init /bin/bash
> then I lose any echoing of input characters to the shell (due to
> open_init_pty turning it off), but I can enter commands and execute
> them, or run stty sane to regain echoing.  But I don't think that has
> ever been supported since the introduction of open_init_pty in 2005
> (policycoreutils 1.21.2).  What's the use case for it?
>
> Side bar: run_init (and open_init_pty) are no longer packaged by Fedora
> since systemd renders it unnecessary, and even prior to that, Fedora
> policy enabled DIRECT_INITRC=y in build.conf, and therefore run_init
> wasn't required for typical operation (maybe under -mls policy it was
> still needed, not sure). Possibly we should move run_init out of
> policycoreutils into its own subdirectory in the selinux userspace tree
> to reflect this transition and start deprecating it.
run_init and newrole executables are still packaged in debian but in a 
different package that is not pulled by anything, so people that need it 
have to manually install it.

Re: run_init messes up terminal settings

[Stephen Smalley]

On Mon, 2017-06-26 at 15:56 +0200, Laurent Bigonville wrote:
> Le 26/06/17 à 15:08, Stephen Smalley a écrit :
> > On Sat, 2017-06-24 at 12:20 +0200, Laurent Bigonville wrote:
> > > Hello,
> > > Russell opened the following bug regarding run_init in the debian
> > > bts:
> > > ====
> > > [...]
> > > It turns out that the problem was not running $(arch), but
> > > running
> > > run_init in
> > > the shell it spawned.  Below is an example of reproducing this,
> > > the
> > > first time
> > > run_init performs as expected.  The second time is fails without
> > > me
> > > even
> > > typing a password or pressing ENTER.  The result is the same with
> > > any
> > > command,
> > > but ls is just a good example.  This happens no matter what shell
> > > is
> > > spawned
> > > (whether it's ssh, su, or just an Xterm), run_init seems
> > > generally
> > > broken with
> > > the 4.9.0-2-amd64/4.9.13-1 kernel at least.
> > > 
> > > NB I can't rule out the possibility of a kernel bug at this
> > > stage.  But at
> > > this time it seems best to assume it's a run_init bug until
> > > proven
> > > otherwise.
> > > 
> > > Sorry for the inconvenience Andreas.
> > > 
> > > # run_init ls /boot
> > > Authenticating root.
> > > Password:
> > > config-4.9.0-2-amd64      lost+found                System.map-
> > > 4.9.0-
> > > 3-amd64
> > > config-4.9.0-3-amd64      memtest86+.bin            vmlinuz-
> > > 4.9.0-2-
> > > amd64
> > > grub                      memtest86+_multiboot.bin  vmlinuz-
> > > 4.9.0-3-
> > > amd64
> > > initrd.img-4.9.0-2-amd64  real
> > > initrd.img-4.9.0-3-amd64  System.map-4.9.0-2-amd64
> > > # run_init ls /boot
> > > Authenticating root.
> > > Password:
> > > run_init: incorrect password for root
> > > authentication failed.
> > > #
> > > ====
> > > I can reproduce this with 2.7-rc3, run_init is compiled with pam
> > > and
> > > audit support.
> > > An idea what could happen here?
> > > Regards,
> > > Laurent Bigonville
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863187
> > 
> > I don't think this could have ever worked under run_init since
> > open_init_pty was introduced (originally from Debian); note that
> > open_init_pty does alter terminal settings.
> > 
> > I don't quite follow the example given above.  It shows executing
> > run_init twice with ls /boot as the arguments, which is not running
> > run_init within run_init.  That works fine for me.
> 
> I just re-tried again and I can definitely reproduce this in debian 
> unstable. My complete test case is:
> 
> sudo -i
> <type the password>
> run_init ls /boot
> <type the password>
> <ls output>
> run_init ls /boot
> <error>
> 
> If I exit the shell started by sudo, run_init will works again for
> one 
> invocation before getting the error again.

Hmm...I couldn't reproduce on Fedora with the upstream selinux
userspace.  The above sequence works for me no matter how many times I
run run_init ls /boot.

What I did notice was that if I tried running two run_init commands
immediately after each other ala:
run_init id && run_init id
then the second one would fail on the user authentication.
(in comparison, su -c id && su -c id works fine.)

But if I try again manually, run_init works fine.

strace -f of the failed run_init (ala run_init id && strace -f run_init
id 2> err.txt) showed that it ends up getting -1 with errno EAGAIN on
the attempted read of the password from descriptor 0 (stdin).

This seems to be due to open_init_pty.  If I remove
/usr/sbin/open_init_pty, the above works without any problem (run_init
falls back to running the command directly if open_init_pty does not
exist; open_init_pty was always optional and introduced by Debian).

In particular, open_init_pty marks stdin and stdout non-blocking before
entering its event loop to handle I/O between the caller and the child.
 If you comment those setfd_nonblock() calls out, then the second
authentication works, but that will have other effects.

I'd be inclined to just drop open_init_pty (for that matter, I'd like
to deprecate/drop run_init entirely, but I guess it might be needed if
not using DIRECT_INITRC=y and not using systemd).

> 
> > If I try something like:
> > run_init run_init ls /boot
> > which actually runs run_init within run_init, then that also works
> > for
> > me without problem.
> > 
> > If I try something like:
> > run_init /bin/bash
> > then I lose any echoing of input characters to the shell (due to
> > open_init_pty turning it off), but I can enter commands and execute
> > them, or run stty sane to regain echoing.  But I don't think that
> > has
> > ever been supported since the introduction of open_init_pty in 2005
> > (policycoreutils 1.21.2).  What's the use case for it?
> > 
> > Side bar: run_init (and open_init_pty) are no longer packaged by
> > Fedora
> > since systemd renders it unnecessary, and even prior to that,
> > Fedora
> > policy enabled DIRECT_INITRC=y in build.conf, and therefore
> > run_init
> > wasn't required for typical operation (maybe under -mls policy it
> > was
> > still needed, not sure). Possibly we should move run_init out of
> > policycoreutils into its own subdirectory in the selinux userspace
> > tree
> > to reflect this transition and start deprecating it.
> 
> run_init and newrole executables are still packaged in debian but in
> a 
> different package that is not pulled by anything, so people that need
> it 
> have to manually install it.

Re: run_init messes up terminal settings

[Stephen Smalley]

On Mon, 2017-06-26 at 15:26 +0200, Dominick Grift wrote:
> On Mon, Jun 26, 2017 at 09:08:16AM -0400, Stephen Smalley wrote:
> > On Sat, 2017-06-24 at 12:20 +0200, Laurent Bigonville wrote:
> > > Hello,
> > > Russell opened the following bug regarding run_init in the debian
> > > bts:
> > > ====
> > > [...]
> > > It turns out that the problem was not running $(arch), but
> > > running
> > > run_init in 
> > > the shell it spawned.  Below is an example of reproducing this,
> > > the
> > > first time 
> > > run_init performs as expected.  The second time is fails without
> > > me
> > > even 
> > > typing a password or pressing ENTER.  The result is the same with
> > > any
> > > command, 
> > > but ls is just a good example.  This happens no matter what shell
> > > is
> > > spawned 
> > > (whether it's ssh, su, or just an Xterm), run_init seems
> > > generally
> > > broken with 
> > > the 4.9.0-2-amd64/4.9.13-1 kernel at least.
> > > 
> > > NB I can't rule out the possibility of a kernel bug at this
> > > stage.  But at 
> > > this time it seems best to assume it's a run_init bug until
> > > proven
> > > otherwise.
> > > 
> > > Sorry for the inconvenience Andreas.
> > > 
> > > # run_init ls /boot
> > > Authenticating root.
> > > Password: 
> > > config-4.9.0-2-amd64      lost+found                System.map-
> > > 4.9.0-
> > > 3-amd64
> > > config-4.9.0-3-amd64      memtest86+.bin            vmlinuz-
> > > 4.9.0-2-
> > > amd64
> > > grub                      memtest86+_multiboot.bin  vmlinuz-
> > > 4.9.0-3-
> > > amd64
> > > initrd.img-4.9.0-2-amd64  real
> > > initrd.img-4.9.0-3-amd64  System.map-4.9.0-2-amd64
> > > # run_init ls /boot
> > > Authenticating root.
> > > Password: 
> > > run_init: incorrect password for root
> > > authentication failed.
> > > # 
> > > ====
> > > I can reproduce this with 2.7-rc3, run_init is compiled with pam
> > > and
> > > audit support.
> > > An idea what could happen here?
> > > Regards,
> > > Laurent Bigonville
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863187
> > 
> > I don't think this could have ever worked under run_init since
> > open_init_pty was introduced (originally from Debian); note that
> > open_init_pty does alter terminal settings.
> > 
> > I don't quite follow the example given above.  It shows executing
> > run_init twice with ls /boot as the arguments, which is not running
> > run_init within run_init.  That works fine for me.
> > 
> > If I try something like:
> > run_init run_init ls /boot
> > which actually runs run_init within run_init, then that also works
> > for
> > me without problem.
> > 
> > If I try something like:
> > run_init /bin/bash
> > then I lose any echoing of input characters to the shell (due to
> > open_init_pty turning it off), but I can enter commands and execute
> > them, or run stty sane to regain echoing.  But I don't think that
> > has
> > ever been supported since the introduction of open_init_pty in 2005
> > (policycoreutils 1.21.2).  What's the use case for it?
> > 
> > Side bar: run_init (and open_init_pty) are no longer packaged by
> > Fedora
> > since systemd renders it unnecessary, and even prior to that,
> > Fedora
> > policy enabled DIRECT_INITRC=y in build.conf, and therefore
> > run_init
> 
> Correct me if i am wrong but fedora has DIRECT_INITRC=n AFAICT
> 
> https://src.fedoraproject.org/cgit/rpms/selinux-policy.git/tree/selin
> ux-policy.spec#n173
> https://src.fedoraproject.org/cgit/rpms/selinux-policy.git/tree/selin
> ux-policy.spec#n393
> 
> I vaguely recall that in a strict environment one still might need
> run_init for the `update aliases` functionality in redhar-based
> distributions.. i might be wrong though

run_init is no longer packaged in Fedora at all (see
policycoreutils.spec, which removes it during %install so that it will
not be packaged).  Looking at the ChangeLog, this happened in 2012:
* Mon Nov 5 2012 Dan Walsh <dwalsh@redhat.com> - 2.1.12-25
- Remove run_init, no longer needed with systemd.

Thus, DIRECT_INITRC=y is no longer required either, for the same reason
(obsoleted by systemd).  Prior to that change, Fedora built with
DIRECT_INITRC=y for -targeted policy; only -mls and -strict built with
DIRECT_INITRC=n and needed run_init.

> 
> > wasn't required for typical operation (maybe under -mls policy it
> > was
> > still needed, not sure). Possibly we should move run_init out of
> > policycoreutils into its own subdirectory in the selinux userspace
> > tree
> > to reflect this transition and start deprecating it.
> > 
> 
> 

Re: run_init messes up terminal settings

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 6006 bytes --]

On Mon, Jun 26, 2017 at 11:50:10AM -0400, Stephen Smalley wrote:
> On Mon, 2017-06-26 at 15:26 +0200, Dominick Grift wrote:
> > On Mon, Jun 26, 2017 at 09:08:16AM -0400, Stephen Smalley wrote:
> > > On Sat, 2017-06-24 at 12:20 +0200, Laurent Bigonville wrote:
> > > > Hello,
> > > > Russell opened the following bug regarding run_init in the debian
> > > > bts:
> > > > ====
> > > > [...]
> > > > It turns out that the problem was not running $(arch), but
> > > > running
> > > > run_init in 
> > > > the shell it spawned.  Below is an example of reproducing this,
> > > > the
> > > > first time 
> > > > run_init performs as expected.  The second time is fails without
> > > > me
> > > > even 
> > > > typing a password or pressing ENTER.  The result is the same with
> > > > any
> > > > command, 
> > > > but ls is just a good example.  This happens no matter what shell
> > > > is
> > > > spawned 
> > > > (whether it's ssh, su, or just an Xterm), run_init seems
> > > > generally
> > > > broken with 
> > > > the 4.9.0-2-amd64/4.9.13-1 kernel at least.
> > > > 
> > > > NB I can't rule out the possibility of a kernel bug at this
> > > > stage.  But at 
> > > > this time it seems best to assume it's a run_init bug until
> > > > proven
> > > > otherwise.
> > > > 
> > > > Sorry for the inconvenience Andreas.
> > > > 
> > > > # run_init ls /boot
> > > > Authenticating root.
> > > > Password: 
> > > > config-4.9.0-2-amd64      lost+found                System.map-
> > > > 4.9.0-
> > > > 3-amd64
> > > > config-4.9.0-3-amd64      memtest86+.bin            vmlinuz-
> > > > 4.9.0-2-
> > > > amd64
> > > > grub                      memtest86+_multiboot.bin  vmlinuz-
> > > > 4.9.0-3-
> > > > amd64
> > > > initrd.img-4.9.0-2-amd64  real
> > > > initrd.img-4.9.0-3-amd64  System.map-4.9.0-2-amd64
> > > > # run_init ls /boot
> > > > Authenticating root.
> > > > Password: 
> > > > run_init: incorrect password for root
> > > > authentication failed.
> > > > # 
> > > > ====
> > > > I can reproduce this with 2.7-rc3, run_init is compiled with pam
> > > > and
> > > > audit support.
> > > > An idea what could happen here?
> > > > Regards,
> > > > Laurent Bigonville
> > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863187
> > > 
> > > I don't think this could have ever worked under run_init since
> > > open_init_pty was introduced (originally from Debian); note that
> > > open_init_pty does alter terminal settings.
> > > 
> > > I don't quite follow the example given above.  It shows executing
> > > run_init twice with ls /boot as the arguments, which is not running
> > > run_init within run_init.  That works fine for me.
> > > 
> > > If I try something like:
> > > run_init run_init ls /boot
> > > which actually runs run_init within run_init, then that also works
> > > for
> > > me without problem.
> > > 
> > > If I try something like:
> > > run_init /bin/bash
> > > then I lose any echoing of input characters to the shell (due to
> > > open_init_pty turning it off), but I can enter commands and execute
> > > them, or run stty sane to regain echoing.  But I don't think that
> > > has
> > > ever been supported since the introduction of open_init_pty in 2005
> > > (policycoreutils 1.21.2).  What's the use case for it?
> > > 
> > > Side bar: run_init (and open_init_pty) are no longer packaged by
> > > Fedora
> > > since systemd renders it unnecessary, and even prior to that,
> > > Fedora
> > > policy enabled DIRECT_INITRC=y in build.conf, and therefore
> > > run_init
> > 
> > Correct me if i am wrong but fedora has DIRECT_INITRC=n AFAICT
> > 
> > https://src.fedoraproject.org/cgit/rpms/selinux-policy.git/tree/selin
> > ux-policy.spec#n173
> > https://src.fedoraproject.org/cgit/rpms/selinux-policy.git/tree/selin
> > ux-policy.spec#n393
> > 
> > I vaguely recall that in a strict environment one still might need
> > run_init for the `update aliases` functionality in redhar-based
> > distributions.. i might be wrong though
> 
> run_init is no longer packaged in Fedora at all (see
> policycoreutils.spec, which removes it during %install so that it will
> not be packaged).  Looking at the ChangeLog, this happened in 2012:
> * Mon Nov 5 2012 Dan Walsh <dwalsh@redhat.com> - 2.1.12-25
> - Remove run_init, no longer needed with systemd.
> 
> Thus, DIRECT_INITRC=y is no longer required either, for the same reason
> (obsoleted by systemd).  Prior to that change, Fedora built with
> DIRECT_INITRC=y for -targeted policy; only -mls and -strict built with
> DIRECT_INITRC=n and needed run_init.

Maybe, I recall that previously Fedora use to hack around DIRECT_INITRC with unconfined_t but AFAICR it always applied to sysadm_t.
Does not make any difference though. However I do, kind of, wonder if sysadm_t is currently able to update the aliases db with sendmail (but then again it has been a long time since redhat shipped with sendmail enabled by default)

Nevertheless, gentoo relies on run_init for openrc, and in debian systemd is optional (i think)

Normally I am all for removing as much as possible, but with run_init I have mixed feelings, because systemd has been and is a headache IMHO

No one was able to confirm it but last lime i tried the "service enable/disable" access vector was broken. Atleast with good old sysvinit/upstart we didnt have to depend selinux extension code to be able to control this as it was all transparent.

> 
> > 
> > > wasn't required for typical operation (maybe under -mls policy it
> > > was
> > > still needed, not sure). Possibly we should move run_init out of
> > > policycoreutils into its own subdirectory in the selinux userspace
> > > tree
> > > to reflect this transition and start deprecating it.
> > > 
> > 
> > 

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: run_init messes up terminal settings

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 6997 bytes --]

On Mon, Jun 26, 2017 at 01:22:41PM -0400, Stephen Smalley wrote:
> On Mon, 2017-06-26 at 18:45 +0200, Dominick Grift wrote:
> > On Mon, Jun 26, 2017 at 11:50:10AM -0400, Stephen Smalley wrote:
> > > On Mon, 2017-06-26 at 15:26 +0200, Dominick Grift wrote:
> > > > On Mon, Jun 26, 2017 at 09:08:16AM -0400, Stephen Smalley wrote:
> > > > > On Sat, 2017-06-24 at 12:20 +0200, Laurent Bigonville wrote:
> > > > > > Hello,
> > > > > > Russell opened the following bug regarding run_init in the
> > > > > > debian
> > > > > > bts:
> > > > > > ====
> > > > > > [...]
> > > > > > It turns out that the problem was not running $(arch), but
> > > > > > running
> > > > > > run_init in 
> > > > > > the shell it spawned.  Below is an example of reproducing
> > > > > > this,
> > > > > > the
> > > > > > first time 
> > > > > > run_init performs as expected.  The second time is fails
> > > > > > without
> > > > > > me
> > > > > > even 
> > > > > > typing a password or pressing ENTER.  The result is the same
> > > > > > with
> > > > > > any
> > > > > > command, 
> > > > > > but ls is just a good example.  This happens no matter what
> > > > > > shell
> > > > > > is
> > > > > > spawned 
> > > > > > (whether it's ssh, su, or just an Xterm), run_init seems
> > > > > > generally
> > > > > > broken with 
> > > > > > the 4.9.0-2-amd64/4.9.13-1 kernel at least.
> > > > > > 
> > > > > > NB I can't rule out the possibility of a kernel bug at this
> > > > > > stage.  But at 
> > > > > > this time it seems best to assume it's a run_init bug until
> > > > > > proven
> > > > > > otherwise.
> > > > > > 
> > > > > > Sorry for the inconvenience Andreas.
> > > > > > 
> > > > > > # run_init ls /boot
> > > > > > Authenticating root.
> > > > > > Password: 
> > > > > > config-4.9.0-2-
> > > > > > amd64      lost+found                System.map-
> > > > > > 4.9.0-
> > > > > > 3-amd64
> > > > > > config-4.9.0-3-amd64      memtest86+.bin            vmlinuz-
> > > > > > 4.9.0-2-
> > > > > > amd64
> > > > > > grub                      memtest86+_multiboot.bin  vmlinuz-
> > > > > > 4.9.0-3-
> > > > > > amd64
> > > > > > initrd.img-4.9.0-2-amd64  real
> > > > > > initrd.img-4.9.0-3-amd64  System.map-4.9.0-2-amd64
> > > > > > # run_init ls /boot
> > > > > > Authenticating root.
> > > > > > Password: 
> > > > > > run_init: incorrect password for root
> > > > > > authentication failed.
> > > > > > # 
> > > > > > ====
> > > > > > I can reproduce this with 2.7-rc3, run_init is compiled with
> > > > > > pam
> > > > > > and
> > > > > > audit support.
> > > > > > An idea what could happen here?
> > > > > > Regards,
> > > > > > Laurent Bigonville
> > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863187
> > > > > 
> > > > > I don't think this could have ever worked under run_init since
> > > > > open_init_pty was introduced (originally from Debian); note
> > > > > that
> > > > > open_init_pty does alter terminal settings.
> > > > > 
> > > > > I don't quite follow the example given above.  It shows
> > > > > executing
> > > > > run_init twice with ls /boot as the arguments, which is not
> > > > > running
> > > > > run_init within run_init.  That works fine for me.
> > > > > 
> > > > > If I try something like:
> > > > > run_init run_init ls /boot
> > > > > which actually runs run_init within run_init, then that also
> > > > > works
> > > > > for
> > > > > me without problem.
> > > > > 
> > > > > If I try something like:
> > > > > run_init /bin/bash
> > > > > then I lose any echoing of input characters to the shell (due
> > > > > to
> > > > > open_init_pty turning it off), but I can enter commands and
> > > > > execute
> > > > > them, or run stty sane to regain echoing.  But I don't think
> > > > > that
> > > > > has
> > > > > ever been supported since the introduction of open_init_pty in
> > > > > 2005
> > > > > (policycoreutils 1.21.2).  What's the use case for it?
> > > > > 
> > > > > Side bar: run_init (and open_init_pty) are no longer packaged
> > > > > by
> > > > > Fedora
> > > > > since systemd renders it unnecessary, and even prior to that,
> > > > > Fedora
> > > > > policy enabled DIRECT_INITRC=y in build.conf, and therefore
> > > > > run_init
> > > > 
> > > > Correct me if i am wrong but fedora has DIRECT_INITRC=n AFAICT
> > > > 
> > > > https://src.fedoraproject.org/cgit/rpms/selinux-policy.git/tree/s
> > > > elin
> > > > ux-policy.spec#n173
> > > > https://src.fedoraproject.org/cgit/rpms/selinux-policy.git/tree/s
> > > > elin
> > > > ux-policy.spec#n393
> > > > 
> > > > I vaguely recall that in a strict environment one still might
> > > > need
> > > > run_init for the `update aliases` functionality in redhar-based
> > > > distributions.. i might be wrong though
> > > 
> > > run_init is no longer packaged in Fedora at all (see
> > > policycoreutils.spec, which removes it during %install so that it
> > > will
> > > not be packaged).  Looking at the ChangeLog, this happened in 2012:
> > > * Mon Nov 5 2012 Dan Walsh <dwalsh@redhat.com> - 2.1.12-25
> > > - Remove run_init, no longer needed with systemd.
> > > 
> > > Thus, DIRECT_INITRC=y is no longer required either, for the same
> > > reason
> > > (obsoleted by systemd).  Prior to that change, Fedora built with
> > > DIRECT_INITRC=y for -targeted policy; only -mls and -strict built
> > > with
> > > DIRECT_INITRC=n and needed run_init.
> > 
> > Maybe, I recall that previously Fedora use to hack around
> > DIRECT_INITRC with unconfined_t but AFAICR it always applied to
> > sysadm_t.
> > Does not make any difference though. However I do, kind of, wonder if
> > sysadm_t is currently able to update the aliases db with sendmail
> > (but then again it has been a long time since redhat shipped with
> > sendmail enabled by default)
> > 
> > Nevertheless, gentoo relies on run_init for openrc, and in debian
> > systemd is optional (i think)
> > 
> > Normally I am all for removing as much as possible, but with run_init
> > I have mixed feelings, because systemd has been and is a headache
> > IMHO
> > 
> > No one was able to confirm it but last lime i tried the "service
> > enable/disable" access vector was broken. Atleast with good old
> > sysvinit/upstart we didnt have to depend selinux extension code to be
> > able to control this as it was all transparent.
> 
> You'll have to clarify what you mean by "broken" here, preferably with
> a reproducer.
> 

In fedora 26 i noticed that the "service disable/enable" checks were no longer performed.

In other words confined administrators were able to disable/enable arbitrary service units.

https://tfirg.undo.it/wordpress/dssp2-confined-administrators-and-a-what-looks-to-be-a-bug-in-systemd-233/


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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: run_init messes up terminal settings

[Stephen Smalley]

On Mon, 2017-06-26 at 18:45 +0200, Dominick Grift wrote:
> On Mon, Jun 26, 2017 at 11:50:10AM -0400, Stephen Smalley wrote:
> > On Mon, 2017-06-26 at 15:26 +0200, Dominick Grift wrote:
> > > On Mon, Jun 26, 2017 at 09:08:16AM -0400, Stephen Smalley wrote:
> > > > On Sat, 2017-06-24 at 12:20 +0200, Laurent Bigonville wrote:
> > > > > Hello,
> > > > > Russell opened the following bug regarding run_init in the
> > > > > debian
> > > > > bts:
> > > > > ====
> > > > > [...]
> > > > > It turns out that the problem was not running $(arch), but
> > > > > running
> > > > > run_init in 
> > > > > the shell it spawned.  Below is an example of reproducing
> > > > > this,
> > > > > the
> > > > > first time 
> > > > > run_init performs as expected.  The second time is fails
> > > > > without
> > > > > me
> > > > > even 
> > > > > typing a password or pressing ENTER.  The result is the same
> > > > > with
> > > > > any
> > > > > command, 
> > > > > but ls is just a good example.  This happens no matter what
> > > > > shell
> > > > > is
> > > > > spawned 
> > > > > (whether it's ssh, su, or just an Xterm), run_init seems
> > > > > generally
> > > > > broken with 
> > > > > the 4.9.0-2-amd64/4.9.13-1 kernel at least.
> > > > > 
> > > > > NB I can't rule out the possibility of a kernel bug at this
> > > > > stage.  But at 
> > > > > this time it seems best to assume it's a run_init bug until
> > > > > proven
> > > > > otherwise.
> > > > > 
> > > > > Sorry for the inconvenience Andreas.
> > > > > 
> > > > > # run_init ls /boot
> > > > > Authenticating root.
> > > > > Password: 
> > > > > config-4.9.0-2-
> > > > > amd64      lost+found                System.map-
> > > > > 4.9.0-
> > > > > 3-amd64
> > > > > config-4.9.0-3-amd64      memtest86+.bin            vmlinuz-
> > > > > 4.9.0-2-
> > > > > amd64
> > > > > grub                      memtest86+_multiboot.bin  vmlinuz-
> > > > > 4.9.0-3-
> > > > > amd64
> > > > > initrd.img-4.9.0-2-amd64  real
> > > > > initrd.img-4.9.0-3-amd64  System.map-4.9.0-2-amd64
> > > > > # run_init ls /boot
> > > > > Authenticating root.
> > > > > Password: 
> > > > > run_init: incorrect password for root
> > > > > authentication failed.
> > > > > # 
> > > > > ====
> > > > > I can reproduce this with 2.7-rc3, run_init is compiled with
> > > > > pam
> > > > > and
> > > > > audit support.
> > > > > An idea what could happen here?
> > > > > Regards,
> > > > > Laurent Bigonville
> > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863187
> > > > 
> > > > I don't think this could have ever worked under run_init since
> > > > open_init_pty was introduced (originally from Debian); note
> > > > that
> > > > open_init_pty does alter terminal settings.
> > > > 
> > > > I don't quite follow the example given above.  It shows
> > > > executing
> > > > run_init twice with ls /boot as the arguments, which is not
> > > > running
> > > > run_init within run_init.  That works fine for me.
> > > > 
> > > > If I try something like:
> > > > run_init run_init ls /boot
> > > > which actually runs run_init within run_init, then that also
> > > > works
> > > > for
> > > > me without problem.
> > > > 
> > > > If I try something like:
> > > > run_init /bin/bash
> > > > then I lose any echoing of input characters to the shell (due
> > > > to
> > > > open_init_pty turning it off), but I can enter commands and
> > > > execute
> > > > them, or run stty sane to regain echoing.  But I don't think
> > > > that
> > > > has
> > > > ever been supported since the introduction of open_init_pty in
> > > > 2005
> > > > (policycoreutils 1.21.2).  What's the use case for it?
> > > > 
> > > > Side bar: run_init (and open_init_pty) are no longer packaged
> > > > by
> > > > Fedora
> > > > since systemd renders it unnecessary, and even prior to that,
> > > > Fedora
> > > > policy enabled DIRECT_INITRC=y in build.conf, and therefore
> > > > run_init
> > > 
> > > Correct me if i am wrong but fedora has DIRECT_INITRC=n AFAICT
> > > 
> > > https://src.fedoraproject.org/cgit/rpms/selinux-policy.git/tree/s
> > > elin
> > > ux-policy.spec#n173
> > > https://src.fedoraproject.org/cgit/rpms/selinux-policy.git/tree/s
> > > elin
> > > ux-policy.spec#n393
> > > 
> > > I vaguely recall that in a strict environment one still might
> > > need
> > > run_init for the `update aliases` functionality in redhar-based
> > > distributions.. i might be wrong though
> > 
> > run_init is no longer packaged in Fedora at all (see
> > policycoreutils.spec, which removes it during %install so that it
> > will
> > not be packaged).  Looking at the ChangeLog, this happened in 2012:
> > * Mon Nov 5 2012 Dan Walsh <dwalsh@redhat.com> - 2.1.12-25
> > - Remove run_init, no longer needed with systemd.
> > 
> > Thus, DIRECT_INITRC=y is no longer required either, for the same
> > reason
> > (obsoleted by systemd).  Prior to that change, Fedora built with
> > DIRECT_INITRC=y for -targeted policy; only -mls and -strict built
> > with
> > DIRECT_INITRC=n and needed run_init.
> 
> Maybe, I recall that previously Fedora use to hack around
> DIRECT_INITRC with unconfined_t but AFAICR it always applied to
> sysadm_t.
> Does not make any difference though. However I do, kind of, wonder if
> sysadm_t is currently able to update the aliases db with sendmail
> (but then again it has been a long time since redhat shipped with
> sendmail enabled by default)
> 
> Nevertheless, gentoo relies on run_init for openrc, and in debian
> systemd is optional (i think)
> 
> Normally I am all for removing as much as possible, but with run_init
> I have mixed feelings, because systemd has been and is a headache
> IMHO
> 
> No one was able to confirm it but last lime i tried the "service
> enable/disable" access vector was broken. Atleast with good old
> sysvinit/upstart we didnt have to depend selinux extension code to be
> able to control this as it was all transparent.

You'll have to clarify what you mean by "broken" here, preferably with
a reproducer.

Re: run_init messes up terminal settings

[Stephen Smalley]

On Mon, 2017-06-26 at 19:20 +0200, Dominick Grift wrote:
> On Mon, Jun 26, 2017 at 01:22:41PM -0400, Stephen Smalley wrote:
> > On Mon, 2017-06-26 at 18:45 +0200, Dominick Grift wrote:
> > > On Mon, Jun 26, 2017 at 11:50:10AM -0400, Stephen Smalley wrote:
> > > > On Mon, 2017-06-26 at 15:26 +0200, Dominick Grift wrote:
> > > > > On Mon, Jun 26, 2017 at 09:08:16AM -0400, Stephen Smalley
> > > > > wrote:
> > > > > > On Sat, 2017-06-24 at 12:20 +0200, Laurent Bigonville
> > > > > > wrote:
> > > > > > > Hello,
> > > > > > > Russell opened the following bug regarding run_init in
> > > > > > > the
> > > > > > > debian
> > > > > > > bts:
> > > > > > > ====
> > > > > > > [...]
> > > > > > > It turns out that the problem was not running $(arch),
> > > > > > > but
> > > > > > > running
> > > > > > > run_init in 
> > > > > > > the shell it spawned.  Below is an example of reproducing
> > > > > > > this,
> > > > > > > the
> > > > > > > first time 
> > > > > > > run_init performs as expected.  The second time is fails
> > > > > > > without
> > > > > > > me
> > > > > > > even 
> > > > > > > typing a password or pressing ENTER.  The result is the
> > > > > > > same
> > > > > > > with
> > > > > > > any
> > > > > > > command, 
> > > > > > > but ls is just a good example.  This happens no matter
> > > > > > > what
> > > > > > > shell
> > > > > > > is
> > > > > > > spawned 
> > > > > > > (whether it's ssh, su, or just an Xterm), run_init seems
> > > > > > > generally
> > > > > > > broken with 
> > > > > > > the 4.9.0-2-amd64/4.9.13-1 kernel at least.
> > > > > > > 
> > > > > > > NB I can't rule out the possibility of a kernel bug at
> > > > > > > this
> > > > > > > stage.  But at 
> > > > > > > this time it seems best to assume it's a run_init bug
> > > > > > > until
> > > > > > > proven
> > > > > > > otherwise.
> > > > > > > 
> > > > > > > Sorry for the inconvenience Andreas.
> > > > > > > 
> > > > > > > # run_init ls /boot
> > > > > > > Authenticating root.
> > > > > > > Password: 
> > > > > > > config-4.9.0-2-
> > > > > > > amd64      lost+found                System.map-
> > > > > > > 4.9.0-
> > > > > > > 3-amd64
> > > > > > > config-4.9.0-3-
> > > > > > > amd64      memtest86+.bin            vmlinuz-
> > > > > > > 4.9.0-2-
> > > > > > > amd64
> > > > > > > grub                      memtest86+_multiboot.bin  vmlin
> > > > > > > uz-
> > > > > > > 4.9.0-3-
> > > > > > > amd64
> > > > > > > initrd.img-4.9.0-2-amd64  real
> > > > > > > initrd.img-4.9.0-3-amd64  System.map-4.9.0-2-amd64
> > > > > > > # run_init ls /boot
> > > > > > > Authenticating root.
> > > > > > > Password: 
> > > > > > > run_init: incorrect password for root
> > > > > > > authentication failed.
> > > > > > > # 
> > > > > > > ====
> > > > > > > I can reproduce this with 2.7-rc3, run_init is compiled
> > > > > > > with
> > > > > > > pam
> > > > > > > and
> > > > > > > audit support.
> > > > > > > An idea what could happen here?
> > > > > > > Regards,
> > > > > > > Laurent Bigonville
> > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863187
> > > > > > 
> > > > > > I don't think this could have ever worked under run_init
> > > > > > since
> > > > > > open_init_pty was introduced (originally from Debian); note
> > > > > > that
> > > > > > open_init_pty does alter terminal settings.
> > > > > > 
> > > > > > I don't quite follow the example given above.  It shows
> > > > > > executing
> > > > > > run_init twice with ls /boot as the arguments, which is not
> > > > > > running
> > > > > > run_init within run_init.  That works fine for me.
> > > > > > 
> > > > > > If I try something like:
> > > > > > run_init run_init ls /boot
> > > > > > which actually runs run_init within run_init, then that
> > > > > > also
> > > > > > works
> > > > > > for
> > > > > > me without problem.
> > > > > > 
> > > > > > If I try something like:
> > > > > > run_init /bin/bash
> > > > > > then I lose any echoing of input characters to the shell
> > > > > > (due
> > > > > > to
> > > > > > open_init_pty turning it off), but I can enter commands and
> > > > > > execute
> > > > > > them, or run stty sane to regain echoing.  But I don't
> > > > > > think
> > > > > > that
> > > > > > has
> > > > > > ever been supported since the introduction of open_init_pty
> > > > > > in
> > > > > > 2005
> > > > > > (policycoreutils 1.21.2).  What's the use case for it?
> > > > > > 
> > > > > > Side bar: run_init (and open_init_pty) are no longer
> > > > > > packaged
> > > > > > by
> > > > > > Fedora
> > > > > > since systemd renders it unnecessary, and even prior to
> > > > > > that,
> > > > > > Fedora
> > > > > > policy enabled DIRECT_INITRC=y in build.conf, and therefore
> > > > > > run_init
> > > > > 
> > > > > Correct me if i am wrong but fedora has DIRECT_INITRC=n
> > > > > AFAICT
> > > > > 
> > > > > https://src.fedoraproject.org/cgit/rpms/selinux-policy.git/tr
> > > > > ee/s
> > > > > elin
> > > > > ux-policy.spec#n173
> > > > > https://src.fedoraproject.org/cgit/rpms/selinux-policy.git/tr
> > > > > ee/s
> > > > > elin
> > > > > ux-policy.spec#n393
> > > > > 
> > > > > I vaguely recall that in a strict environment one still might
> > > > > need
> > > > > run_init for the `update aliases` functionality in redhar-
> > > > > based
> > > > > distributions.. i might be wrong though
> > > > 
> > > > run_init is no longer packaged in Fedora at all (see
> > > > policycoreutils.spec, which removes it during %install so that
> > > > it
> > > > will
> > > > not be packaged).  Looking at the ChangeLog, this happened in
> > > > 2012:
> > > > * Mon Nov 5 2012 Dan Walsh <dwalsh@redhat.com> - 2.1.12-25
> > > > - Remove run_init, no longer needed with systemd.
> > > > 
> > > > Thus, DIRECT_INITRC=y is no longer required either, for the
> > > > same
> > > > reason
> > > > (obsoleted by systemd).  Prior to that change, Fedora built
> > > > with
> > > > DIRECT_INITRC=y for -targeted policy; only -mls and -strict
> > > > built
> > > > with
> > > > DIRECT_INITRC=n and needed run_init.
> > > 
> > > Maybe, I recall that previously Fedora use to hack around
> > > DIRECT_INITRC with unconfined_t but AFAICR it always applied to
> > > sysadm_t.
> > > Does not make any difference though. However I do, kind of,
> > > wonder if
> > > sysadm_t is currently able to update the aliases db with sendmail
> > > (but then again it has been a long time since redhat shipped with
> > > sendmail enabled by default)
> > > 
> > > Nevertheless, gentoo relies on run_init for openrc, and in debian
> > > systemd is optional (i think)
> > > 
> > > Normally I am all for removing as much as possible, but with
> > > run_init
> > > I have mixed feelings, because systemd has been and is a headache
> > > IMHO
> > > 
> > > No one was able to confirm it but last lime i tried the "service
> > > enable/disable" access vector was broken. Atleast with good old
> > > sysvinit/upstart we didnt have to depend selinux extension code
> > > to be
> > > able to control this as it was all transparent.
> > 
> > You'll have to clarify what you mean by "broken" here, preferably
> > with
> > a reproducer.
> > 
> 
> In fedora 26 i noticed that the "service disable/enable" checks were
> no longer performed.
> 
> In other words confined administrators were able to disable/enable
> arbitrary service units.
> 
> https://tfirg.undo.it/wordpress/dssp2-confined-administrators-and-a-w
> hat-looks-to-be-a-bug-in-systemd-233/

Did you file a bug (against Fedora)?  Can you reproduce with their
policy?

Re: run_init messes up terminal settings

[Luis Ressel]

[-- Attachment #1: Type: text/plain, Size: 356 bytes --]

On Mon, 26 Jun 2017 11:22:31 -0400
Stephen Smalley <sds@tycho.nsa.gov> wrote:

> for that matter, I'd like to deprecate/drop run_init entirely, but I
> guess it might be needed if not using DIRECT_INITRC=y and not using
> systemd).

Indeed. run_init is needed for openrc and other init systems. Please
don't deprecate it.

Regards,
Luis Ressel

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: run_init messes up terminal settings

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 8672 bytes --]

On Mon, Jun 26, 2017 at 01:41:05PM -0400, Stephen Smalley wrote:
> On Mon, 2017-06-26 at 19:20 +0200, Dominick Grift wrote:
> > On Mon, Jun 26, 2017 at 01:22:41PM -0400, Stephen Smalley wrote:
> > > On Mon, 2017-06-26 at 18:45 +0200, Dominick Grift wrote:
> > > > On Mon, Jun 26, 2017 at 11:50:10AM -0400, Stephen Smalley wrote:
> > > > > On Mon, 2017-06-26 at 15:26 +0200, Dominick Grift wrote:
> > > > > > On Mon, Jun 26, 2017 at 09:08:16AM -0400, Stephen Smalley
> > > > > > wrote:
> > > > > > > On Sat, 2017-06-24 at 12:20 +0200, Laurent Bigonville
> > > > > > > wrote:
> > > > > > > > Hello,
> > > > > > > > Russell opened the following bug regarding run_init in
> > > > > > > > the
> > > > > > > > debian
> > > > > > > > bts:
> > > > > > > > ====
> > > > > > > > [...]
> > > > > > > > It turns out that the problem was not running $(arch),
> > > > > > > > but
> > > > > > > > running
> > > > > > > > run_init in 
> > > > > > > > the shell it spawned.  Below is an example of reproducing
> > > > > > > > this,
> > > > > > > > the
> > > > > > > > first time 
> > > > > > > > run_init performs as expected.  The second time is fails
> > > > > > > > without
> > > > > > > > me
> > > > > > > > even 
> > > > > > > > typing a password or pressing ENTER.  The result is the
> > > > > > > > same
> > > > > > > > with
> > > > > > > > any
> > > > > > > > command, 
> > > > > > > > but ls is just a good example.  This happens no matter
> > > > > > > > what
> > > > > > > > shell
> > > > > > > > is
> > > > > > > > spawned 
> > > > > > > > (whether it's ssh, su, or just an Xterm), run_init seems
> > > > > > > > generally
> > > > > > > > broken with 
> > > > > > > > the 4.9.0-2-amd64/4.9.13-1 kernel at least.
> > > > > > > > 
> > > > > > > > NB I can't rule out the possibility of a kernel bug at
> > > > > > > > this
> > > > > > > > stage.  But at 
> > > > > > > > this time it seems best to assume it's a run_init bug
> > > > > > > > until
> > > > > > > > proven
> > > > > > > > otherwise.
> > > > > > > > 
> > > > > > > > Sorry for the inconvenience Andreas.
> > > > > > > > 
> > > > > > > > # run_init ls /boot
> > > > > > > > Authenticating root.
> > > > > > > > Password: 
> > > > > > > > config-4.9.0-2-
> > > > > > > > amd64      lost+found                System.map-
> > > > > > > > 4.9.0-
> > > > > > > > 3-amd64
> > > > > > > > config-4.9.0-3-
> > > > > > > > amd64      memtest86+.bin            vmlinuz-
> > > > > > > > 4.9.0-2-
> > > > > > > > amd64
> > > > > > > > grub                      memtest86+_multiboot.bin  vmlin
> > > > > > > > uz-
> > > > > > > > 4.9.0-3-
> > > > > > > > amd64
> > > > > > > > initrd.img-4.9.0-2-amd64  real
> > > > > > > > initrd.img-4.9.0-3-amd64  System.map-4.9.0-2-amd64
> > > > > > > > # run_init ls /boot
> > > > > > > > Authenticating root.
> > > > > > > > Password: 
> > > > > > > > run_init: incorrect password for root
> > > > > > > > authentication failed.
> > > > > > > > # 
> > > > > > > > ====
> > > > > > > > I can reproduce this with 2.7-rc3, run_init is compiled
> > > > > > > > with
> > > > > > > > pam
> > > > > > > > and
> > > > > > > > audit support.
> > > > > > > > An idea what could happen here?
> > > > > > > > Regards,
> > > > > > > > Laurent Bigonville
> > > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863187
> > > > > > > 
> > > > > > > I don't think this could have ever worked under run_init
> > > > > > > since
> > > > > > > open_init_pty was introduced (originally from Debian); note
> > > > > > > that
> > > > > > > open_init_pty does alter terminal settings.
> > > > > > > 
> > > > > > > I don't quite follow the example given above.  It shows
> > > > > > > executing
> > > > > > > run_init twice with ls /boot as the arguments, which is not
> > > > > > > running
> > > > > > > run_init within run_init.  That works fine for me.
> > > > > > > 
> > > > > > > If I try something like:
> > > > > > > run_init run_init ls /boot
> > > > > > > which actually runs run_init within run_init, then that
> > > > > > > also
> > > > > > > works
> > > > > > > for
> > > > > > > me without problem.
> > > > > > > 
> > > > > > > If I try something like:
> > > > > > > run_init /bin/bash
> > > > > > > then I lose any echoing of input characters to the shell
> > > > > > > (due
> > > > > > > to
> > > > > > > open_init_pty turning it off), but I can enter commands and
> > > > > > > execute
> > > > > > > them, or run stty sane to regain echoing.  But I don't
> > > > > > > think
> > > > > > > that
> > > > > > > has
> > > > > > > ever been supported since the introduction of open_init_pty
> > > > > > > in
> > > > > > > 2005
> > > > > > > (policycoreutils 1.21.2).  What's the use case for it?
> > > > > > > 
> > > > > > > Side bar: run_init (and open_init_pty) are no longer
> > > > > > > packaged
> > > > > > > by
> > > > > > > Fedora
> > > > > > > since systemd renders it unnecessary, and even prior to
> > > > > > > that,
> > > > > > > Fedora
> > > > > > > policy enabled DIRECT_INITRC=y in build.conf, and therefore
> > > > > > > run_init
> > > > > > 
> > > > > > Correct me if i am wrong but fedora has DIRECT_INITRC=n
> > > > > > AFAICT
> > > > > > 
> > > > > > https://src.fedoraproject.org/cgit/rpms/selinux-policy.git/tr
> > > > > > ee/s
> > > > > > elin
> > > > > > ux-policy.spec#n173
> > > > > > https://src.fedoraproject.org/cgit/rpms/selinux-policy.git/tr
> > > > > > ee/s
> > > > > > elin
> > > > > > ux-policy.spec#n393
> > > > > > 
> > > > > > I vaguely recall that in a strict environment one still might
> > > > > > need
> > > > > > run_init for the `update aliases` functionality in redhar-
> > > > > > based
> > > > > > distributions.. i might be wrong though
> > > > > 
> > > > > run_init is no longer packaged in Fedora at all (see
> > > > > policycoreutils.spec, which removes it during %install so that
> > > > > it
> > > > > will
> > > > > not be packaged).  Looking at the ChangeLog, this happened in
> > > > > 2012:
> > > > > * Mon Nov 5 2012 Dan Walsh <dwalsh@redhat.com> - 2.1.12-25
> > > > > - Remove run_init, no longer needed with systemd.
> > > > > 
> > > > > Thus, DIRECT_INITRC=y is no longer required either, for the
> > > > > same
> > > > > reason
> > > > > (obsoleted by systemd).  Prior to that change, Fedora built
> > > > > with
> > > > > DIRECT_INITRC=y for -targeted policy; only -mls and -strict
> > > > > built
> > > > > with
> > > > > DIRECT_INITRC=n and needed run_init.
> > > > 
> > > > Maybe, I recall that previously Fedora use to hack around
> > > > DIRECT_INITRC with unconfined_t but AFAICR it always applied to
> > > > sysadm_t.
> > > > Does not make any difference though. However I do, kind of,
> > > > wonder if
> > > > sysadm_t is currently able to update the aliases db with sendmail
> > > > (but then again it has been a long time since redhat shipped with
> > > > sendmail enabled by default)
> > > > 
> > > > Nevertheless, gentoo relies on run_init for openrc, and in debian
> > > > systemd is optional (i think)
> > > > 
> > > > Normally I am all for removing as much as possible, but with
> > > > run_init
> > > > I have mixed feelings, because systemd has been and is a headache
> > > > IMHO
> > > > 
> > > > No one was able to confirm it but last lime i tried the "service
> > > > enable/disable" access vector was broken. Atleast with good old
> > > > sysvinit/upstart we didnt have to depend selinux extension code
> > > > to be
> > > > able to control this as it was all transparent.
> > > 
> > > You'll have to clarify what you mean by "broken" here, preferably
> > > with
> > > a reproducer.
> > > 
> > 
> > In fedora 26 i noticed that the "service disable/enable" checks were
> > no longer performed.
> > 
> > In other words confined administrators were able to disable/enable
> > arbitrary service units.
> > 
> > https://tfirg.undo.it/wordpress/dssp2-confined-administrators-and-a-w
> > hat-looks-to-be-a-bug-in-systemd-233/
> 
> Did you file a bug (against Fedora)?  Can you reproduce with their
> policy?

Not yet i was hoping that some one on IRC or whatever was able to produce it, should be pretty simple to do:

1. use systemd v233 and/or Fedora 26
2. add a auditallow rule like this: (auditallow domain systemd_unit_file_type (service (enable disable)))
3. disable and enable some service units to see if the check is triggered

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: run_init messes up terminal settings

[Stephen Smalley]

On Mon, 2017-06-26 at 19:49 +0200, Dominick Grift wrote:
> On Mon, Jun 26, 2017 at 01:41:05PM -0400, Stephen Smalley wrote:
> > On Mon, 2017-06-26 at 19:20 +0200, Dominick Grift wrote:
> > > On Mon, Jun 26, 2017 at 01:22:41PM -0400, Stephen Smalley wrote:
> > > > On Mon, 2017-06-26 at 18:45 +0200, Dominick Grift wrote:
> > > > > On Mon, Jun 26, 2017 at 11:50:10AM -0400, Stephen Smalley
> > > > > wrote:
> > > > > > On Mon, 2017-06-26 at 15:26 +0200, Dominick Grift wrote:
> > > > > > > On Mon, Jun 26, 2017 at 09:08:16AM -0400, Stephen Smalley
> > > > > > > wrote:
> > > > > > > > On Sat, 2017-06-24 at 12:20 +0200, Laurent Bigonville
> > > > > > > > wrote:
> > > > > > > > > Hello,
> > > > > > > > > Russell opened the following bug regarding run_init
> > > > > > > > > in
> > > > > > > > > the
> > > > > > > > > debian
> > > > > > > > > bts:
> > > > > > > > > ====
> > > > > > > > > [...]
> > > > > > > > > It turns out that the problem was not running
> > > > > > > > > $(arch),
> > > > > > > > > but
> > > > > > > > > running
> > > > > > > > > run_init in 
> > > > > > > > > the shell it spawned.  Below is an example of
> > > > > > > > > reproducing
> > > > > > > > > this,
> > > > > > > > > the
> > > > > > > > > first time 
> > > > > > > > > run_init performs as expected.  The second time is
> > > > > > > > > fails
> > > > > > > > > without
> > > > > > > > > me
> > > > > > > > > even 
> > > > > > > > > typing a password or pressing ENTER.  The result is
> > > > > > > > > the
> > > > > > > > > same
> > > > > > > > > with
> > > > > > > > > any
> > > > > > > > > command, 
> > > > > > > > > but ls is just a good example.  This happens no
> > > > > > > > > matter
> > > > > > > > > what
> > > > > > > > > shell
> > > > > > > > > is
> > > > > > > > > spawned 
> > > > > > > > > (whether it's ssh, su, or just an Xterm), run_init
> > > > > > > > > seems
> > > > > > > > > generally
> > > > > > > > > broken with 
> > > > > > > > > the 4.9.0-2-amd64/4.9.13-1 kernel at least.
> > > > > > > > > 
> > > > > > > > > NB I can't rule out the possibility of a kernel bug
> > > > > > > > > at
> > > > > > > > > this
> > > > > > > > > stage.  But at 
> > > > > > > > > this time it seems best to assume it's a run_init bug
> > > > > > > > > until
> > > > > > > > > proven
> > > > > > > > > otherwise.
> > > > > > > > > 
> > > > > > > > > Sorry for the inconvenience Andreas.
> > > > > > > > > 
> > > > > > > > > # run_init ls /boot
> > > > > > > > > Authenticating root.
> > > > > > > > > Password: 
> > > > > > > > > config-4.9.0-2-
> > > > > > > > > amd64      lost+found                System.map-
> > > > > > > > > 4.9.0-
> > > > > > > > > 3-amd64
> > > > > > > > > config-4.9.0-3-
> > > > > > > > > amd64      memtest86+.bin            vmlinuz-
> > > > > > > > > 4.9.0-2-
> > > > > > > > > amd64
> > > > > > > > > grub                      memtest86+_multiboot.bin  v
> > > > > > > > > mlin
> > > > > > > > > uz-
> > > > > > > > > 4.9.0-3-
> > > > > > > > > amd64
> > > > > > > > > initrd.img-4.9.0-2-amd64  real
> > > > > > > > > initrd.img-4.9.0-3-amd64  System.map-4.9.0-2-amd64
> > > > > > > > > # run_init ls /boot
> > > > > > > > > Authenticating root.
> > > > > > > > > Password: 
> > > > > > > > > run_init: incorrect password for root
> > > > > > > > > authentication failed.
> > > > > > > > > # 
> > > > > > > > > ====
> > > > > > > > > I can reproduce this with 2.7-rc3, run_init is
> > > > > > > > > compiled
> > > > > > > > > with
> > > > > > > > > pam
> > > > > > > > > and
> > > > > > > > > audit support.
> > > > > > > > > An idea what could happen here?
> > > > > > > > > Regards,
> > > > > > > > > Laurent Bigonville
> > > > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863
> > > > > > > > > 187
> > > > > > > > 
> > > > > > > > I don't think this could have ever worked under
> > > > > > > > run_init
> > > > > > > > since
> > > > > > > > open_init_pty was introduced (originally from Debian);
> > > > > > > > note
> > > > > > > > that
> > > > > > > > open_init_pty does alter terminal settings.
> > > > > > > > 
> > > > > > > > I don't quite follow the example given above.  It shows
> > > > > > > > executing
> > > > > > > > run_init twice with ls /boot as the arguments, which is
> > > > > > > > not
> > > > > > > > running
> > > > > > > > run_init within run_init.  That works fine for me.
> > > > > > > > 
> > > > > > > > If I try something like:
> > > > > > > > run_init run_init ls /boot
> > > > > > > > which actually runs run_init within run_init, then that
> > > > > > > > also
> > > > > > > > works
> > > > > > > > for
> > > > > > > > me without problem.
> > > > > > > > 
> > > > > > > > If I try something like:
> > > > > > > > run_init /bin/bash
> > > > > > > > then I lose any echoing of input characters to the
> > > > > > > > shell
> > > > > > > > (due
> > > > > > > > to
> > > > > > > > open_init_pty turning it off), but I can enter commands
> > > > > > > > and
> > > > > > > > execute
> > > > > > > > them, or run stty sane to regain echoing.  But I don't
> > > > > > > > think
> > > > > > > > that
> > > > > > > > has
> > > > > > > > ever been supported since the introduction of
> > > > > > > > open_init_pty
> > > > > > > > in
> > > > > > > > 2005
> > > > > > > > (policycoreutils 1.21.2).  What's the use case for it?
> > > > > > > > 
> > > > > > > > Side bar: run_init (and open_init_pty) are no longer
> > > > > > > > packaged
> > > > > > > > by
> > > > > > > > Fedora
> > > > > > > > since systemd renders it unnecessary, and even prior to
> > > > > > > > that,
> > > > > > > > Fedora
> > > > > > > > policy enabled DIRECT_INITRC=y in build.conf, and
> > > > > > > > therefore
> > > > > > > > run_init
> > > > > > > 
> > > > > > > Correct me if i am wrong but fedora has DIRECT_INITRC=n
> > > > > > > AFAICT
> > > > > > > 
> > > > > > > https://src.fedoraproject.org/cgit/rpms/selinux-policy.gi
> > > > > > > t/tr
> > > > > > > ee/s
> > > > > > > elin
> > > > > > > ux-policy.spec#n173
> > > > > > > https://src.fedoraproject.org/cgit/rpms/selinux-policy.gi
> > > > > > > t/tr
> > > > > > > ee/s
> > > > > > > elin
> > > > > > > ux-policy.spec#n393
> > > > > > > 
> > > > > > > I vaguely recall that in a strict environment one still
> > > > > > > might
> > > > > > > need
> > > > > > > run_init for the `update aliases` functionality in
> > > > > > > redhar-
> > > > > > > based
> > > > > > > distributions.. i might be wrong though
> > > > > > 
> > > > > > run_init is no longer packaged in Fedora at all (see
> > > > > > policycoreutils.spec, which removes it during %install so
> > > > > > that
> > > > > > it
> > > > > > will
> > > > > > not be packaged).  Looking at the ChangeLog, this happened
> > > > > > in
> > > > > > 2012:
> > > > > > * Mon Nov 5 2012 Dan Walsh <dwalsh@redhat.com> - 2.1.12-25
> > > > > > - Remove run_init, no longer needed with systemd.
> > > > > > 
> > > > > > Thus, DIRECT_INITRC=y is no longer required either, for the
> > > > > > same
> > > > > > reason
> > > > > > (obsoleted by systemd).  Prior to that change, Fedora built
> > > > > > with
> > > > > > DIRECT_INITRC=y for -targeted policy; only -mls and -strict
> > > > > > built
> > > > > > with
> > > > > > DIRECT_INITRC=n and needed run_init.
> > > > > 
> > > > > Maybe, I recall that previously Fedora use to hack around
> > > > > DIRECT_INITRC with unconfined_t but AFAICR it always applied
> > > > > to
> > > > > sysadm_t.
> > > > > Does not make any difference though. However I do, kind of,
> > > > > wonder if
> > > > > sysadm_t is currently able to update the aliases db with
> > > > > sendmail
> > > > > (but then again it has been a long time since redhat shipped
> > > > > with
> > > > > sendmail enabled by default)
> > > > > 
> > > > > Nevertheless, gentoo relies on run_init for openrc, and in
> > > > > debian
> > > > > systemd is optional (i think)
> > > > > 
> > > > > Normally I am all for removing as much as possible, but with
> > > > > run_init
> > > > > I have mixed feelings, because systemd has been and is a
> > > > > headache
> > > > > IMHO
> > > > > 
> > > > > No one was able to confirm it but last lime i tried the
> > > > > "service
> > > > > enable/disable" access vector was broken. Atleast with good
> > > > > old
> > > > > sysvinit/upstart we didnt have to depend selinux extension
> > > > > code
> > > > > to be
> > > > > able to control this as it was all transparent.
> > > > 
> > > > You'll have to clarify what you mean by "broken" here,
> > > > preferably
> > > > with
> > > > a reproducer.
> > > > 
> > > 
> > > In fedora 26 i noticed that the "service disable/enable" checks
> > > were
> > > no longer performed.
> > > 
> > > In other words confined administrators were able to
> > > disable/enable
> > > arbitrary service units.
> > > 
> > > https://tfirg.undo.it/wordpress/dssp2-confined-administrators-and
> > > -a-w
> > > hat-looks-to-be-a-bug-in-systemd-233/
> > 
> > Did you file a bug (against Fedora)?  Can you reproduce with their
> > policy?
> 
> Not yet i was hoping that some one on IRC or whatever was able to
> produce it, should be pretty simple to do:
> 
> 1. use systemd v233 and/or Fedora 26
> 2. add a auditallow rule like this: (auditallow domain
> systemd_unit_file_type (service (enable disable)))
> 3. disable and enable some service units to see if the check is
> triggered

I don't see any USER_AVC messages produced by that on F26 (systemd 233)
or F25 (systemd 231).  I do see them on CentOS 7.3 (systemd 119). 
Looks like a regression in systemd.

Re: run_init messes up terminal settings

[Stephen Smalley]

On Mon, 2017-06-26 at 14:24 -0400, Stephen Smalley wrote:
> On Mon, 2017-06-26 at 19:49 +0200, Dominick Grift wrote:
> > On Mon, Jun 26, 2017 at 01:41:05PM -0400, Stephen Smalley wrote:
> > > On Mon, 2017-06-26 at 19:20 +0200, Dominick Grift wrote:
> > > > On Mon, Jun 26, 2017 at 01:22:41PM -0400, Stephen Smalley
> > > > wrote:
> > > > > On Mon, 2017-06-26 at 18:45 +0200, Dominick Grift wrote:
> > > > > > On Mon, Jun 26, 2017 at 11:50:10AM -0400, Stephen Smalley
> > > > > > wrote:
> > > > > > > On Mon, 2017-06-26 at 15:26 +0200, Dominick Grift wrote:
> > > > > > > > On Mon, Jun 26, 2017 at 09:08:16AM -0400, Stephen
> > > > > > > > Smalley
> > > > > > > > wrote:
> > > > > > > > > On Sat, 2017-06-24 at 12:20 +0200, Laurent Bigonville
> > > > > > > > > wrote:
> > > > > > > > > > Hello,
> > > > > > > > > > Russell opened the following bug regarding run_init
> > > > > > > > > > in
> > > > > > > > > > the
> > > > > > > > > > debian
> > > > > > > > > > bts:
> > > > > > > > > > ====
> > > > > > > > > > [...]
> > > > > > > > > > It turns out that the problem was not running
> > > > > > > > > > $(arch),
> > > > > > > > > > but
> > > > > > > > > > running
> > > > > > > > > > run_init in 
> > > > > > > > > > the shell it spawned.  Below is an example of
> > > > > > > > > > reproducing
> > > > > > > > > > this,
> > > > > > > > > > the
> > > > > > > > > > first time 
> > > > > > > > > > run_init performs as expected.  The second time is
> > > > > > > > > > fails
> > > > > > > > > > without
> > > > > > > > > > me
> > > > > > > > > > even 
> > > > > > > > > > typing a password or pressing ENTER.  The result is
> > > > > > > > > > the
> > > > > > > > > > same
> > > > > > > > > > with
> > > > > > > > > > any
> > > > > > > > > > command, 
> > > > > > > > > > but ls is just a good example.  This happens no
> > > > > > > > > > matter
> > > > > > > > > > what
> > > > > > > > > > shell
> > > > > > > > > > is
> > > > > > > > > > spawned 
> > > > > > > > > > (whether it's ssh, su, or just an Xterm), run_init
> > > > > > > > > > seems
> > > > > > > > > > generally
> > > > > > > > > > broken with 
> > > > > > > > > > the 4.9.0-2-amd64/4.9.13-1 kernel at least.
> > > > > > > > > > 
> > > > > > > > > > NB I can't rule out the possibility of a kernel bug
> > > > > > > > > > at
> > > > > > > > > > this
> > > > > > > > > > stage.  But at 
> > > > > > > > > > this time it seems best to assume it's a run_init
> > > > > > > > > > bug
> > > > > > > > > > until
> > > > > > > > > > proven
> > > > > > > > > > otherwise.
> > > > > > > > > > 
> > > > > > > > > > Sorry for the inconvenience Andreas.
> > > > > > > > > > 
> > > > > > > > > > # run_init ls /boot
> > > > > > > > > > Authenticating root.
> > > > > > > > > > Password: 
> > > > > > > > > > config-4.9.0-2-
> > > > > > > > > > amd64      lost+found                System.map-
> > > > > > > > > > 4.9.0-
> > > > > > > > > > 3-amd64
> > > > > > > > > > config-4.9.0-3-
> > > > > > > > > > amd64      memtest86+.bin            vmlinuz-
> > > > > > > > > > 4.9.0-2-
> > > > > > > > > > amd64
> > > > > > > > > > grub                      memtest86+_multiboot.bin 
> > > > > > > > > >  v
> > > > > > > > > > mlin
> > > > > > > > > > uz-
> > > > > > > > > > 4.9.0-3-
> > > > > > > > > > amd64
> > > > > > > > > > initrd.img-4.9.0-2-amd64  real
> > > > > > > > > > initrd.img-4.9.0-3-amd64  System.map-4.9.0-2-amd64
> > > > > > > > > > # run_init ls /boot
> > > > > > > > > > Authenticating root.
> > > > > > > > > > Password: 
> > > > > > > > > > run_init: incorrect password for root
> > > > > > > > > > authentication failed.
> > > > > > > > > > # 
> > > > > > > > > > ====
> > > > > > > > > > I can reproduce this with 2.7-rc3, run_init is
> > > > > > > > > > compiled
> > > > > > > > > > with
> > > > > > > > > > pam
> > > > > > > > > > and
> > > > > > > > > > audit support.
> > > > > > > > > > An idea what could happen here?
> > > > > > > > > > Regards,
> > > > > > > > > > Laurent Bigonville
> > > > > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=8
> > > > > > > > > > 63
> > > > > > > > > > 187
> > > > > > > > > 
> > > > > > > > > I don't think this could have ever worked under
> > > > > > > > > run_init
> > > > > > > > > since
> > > > > > > > > open_init_pty was introduced (originally from
> > > > > > > > > Debian);
> > > > > > > > > note
> > > > > > > > > that
> > > > > > > > > open_init_pty does alter terminal settings.
> > > > > > > > > 
> > > > > > > > > I don't quite follow the example given above.  It
> > > > > > > > > shows
> > > > > > > > > executing
> > > > > > > > > run_init twice with ls /boot as the arguments, which
> > > > > > > > > is
> > > > > > > > > not
> > > > > > > > > running
> > > > > > > > > run_init within run_init.  That works fine for me.
> > > > > > > > > 
> > > > > > > > > If I try something like:
> > > > > > > > > run_init run_init ls /boot
> > > > > > > > > which actually runs run_init within run_init, then
> > > > > > > > > that
> > > > > > > > > also
> > > > > > > > > works
> > > > > > > > > for
> > > > > > > > > me without problem.
> > > > > > > > > 
> > > > > > > > > If I try something like:
> > > > > > > > > run_init /bin/bash
> > > > > > > > > then I lose any echoing of input characters to the
> > > > > > > > > shell
> > > > > > > > > (due
> > > > > > > > > to
> > > > > > > > > open_init_pty turning it off), but I can enter
> > > > > > > > > commands
> > > > > > > > > and
> > > > > > > > > execute
> > > > > > > > > them, or run stty sane to regain echoing.  But I
> > > > > > > > > don't
> > > > > > > > > think
> > > > > > > > > that
> > > > > > > > > has
> > > > > > > > > ever been supported since the introduction of
> > > > > > > > > open_init_pty
> > > > > > > > > in
> > > > > > > > > 2005
> > > > > > > > > (policycoreutils 1.21.2).  What's the use case for
> > > > > > > > > it?
> > > > > > > > > 
> > > > > > > > > Side bar: run_init (and open_init_pty) are no longer
> > > > > > > > > packaged
> > > > > > > > > by
> > > > > > > > > Fedora
> > > > > > > > > since systemd renders it unnecessary, and even prior
> > > > > > > > > to
> > > > > > > > > that,
> > > > > > > > > Fedora
> > > > > > > > > policy enabled DIRECT_INITRC=y in build.conf, and
> > > > > > > > > therefore
> > > > > > > > > run_init
> > > > > > > > 
> > > > > > > > Correct me if i am wrong but fedora has DIRECT_INITRC=n
> > > > > > > > AFAICT
> > > > > > > > 
> > > > > > > > https://src.fedoraproject.org/cgit/rpms/selinux-policy.
> > > > > > > > gi
> > > > > > > > t/tr
> > > > > > > > ee/s
> > > > > > > > elin
> > > > > > > > ux-policy.spec#n173
> > > > > > > > https://src.fedoraproject.org/cgit/rpms/selinux-policy.
> > > > > > > > gi
> > > > > > > > t/tr
> > > > > > > > ee/s
> > > > > > > > elin
> > > > > > > > ux-policy.spec#n393
> > > > > > > > 
> > > > > > > > I vaguely recall that in a strict environment one still
> > > > > > > > might
> > > > > > > > need
> > > > > > > > run_init for the `update aliases` functionality in
> > > > > > > > redhar-
> > > > > > > > based
> > > > > > > > distributions.. i might be wrong though
> > > > > > > 
> > > > > > > run_init is no longer packaged in Fedora at all (see
> > > > > > > policycoreutils.spec, which removes it during %install so
> > > > > > > that
> > > > > > > it
> > > > > > > will
> > > > > > > not be packaged).  Looking at the ChangeLog, this
> > > > > > > happened
> > > > > > > in
> > > > > > > 2012:
> > > > > > > * Mon Nov 5 2012 Dan Walsh <dwalsh@redhat.com> - 2.1.12-
> > > > > > > 25
> > > > > > > - Remove run_init, no longer needed with systemd.
> > > > > > > 
> > > > > > > Thus, DIRECT_INITRC=y is no longer required either, for
> > > > > > > the
> > > > > > > same
> > > > > > > reason
> > > > > > > (obsoleted by systemd).  Prior to that change, Fedora
> > > > > > > built
> > > > > > > with
> > > > > > > DIRECT_INITRC=y for -targeted policy; only -mls and
> > > > > > > -strict
> > > > > > > built
> > > > > > > with
> > > > > > > DIRECT_INITRC=n and needed run_init.
> > > > > > 
> > > > > > Maybe, I recall that previously Fedora use to hack around
> > > > > > DIRECT_INITRC with unconfined_t but AFAICR it always
> > > > > > applied
> > > > > > to
> > > > > > sysadm_t.
> > > > > > Does not make any difference though. However I do, kind of,
> > > > > > wonder if
> > > > > > sysadm_t is currently able to update the aliases db with
> > > > > > sendmail
> > > > > > (but then again it has been a long time since redhat
> > > > > > shipped
> > > > > > with
> > > > > > sendmail enabled by default)
> > > > > > 
> > > > > > Nevertheless, gentoo relies on run_init for openrc, and in
> > > > > > debian
> > > > > > systemd is optional (i think)
> > > > > > 
> > > > > > Normally I am all for removing as much as possible, but
> > > > > > with
> > > > > > run_init
> > > > > > I have mixed feelings, because systemd has been and is a
> > > > > > headache
> > > > > > IMHO
> > > > > > 
> > > > > > No one was able to confirm it but last lime i tried the
> > > > > > "service
> > > > > > enable/disable" access vector was broken. Atleast with good
> > > > > > old
> > > > > > sysvinit/upstart we didnt have to depend selinux extension
> > > > > > code
> > > > > > to be
> > > > > > able to control this as it was all transparent.
> > > > > 
> > > > > You'll have to clarify what you mean by "broken" here,
> > > > > preferably
> > > > > with
> > > > > a reproducer.
> > > > > 
> > > > 
> > > > In fedora 26 i noticed that the "service disable/enable" checks
> > > > were
> > > > no longer performed.
> > > > 
> > > > In other words confined administrators were able to
> > > > disable/enable
> > > > arbitrary service units.
> > > > 
> > > > https://tfirg.undo.it/wordpress/dssp2-confined-administrators-a
> > > > nd
> > > > -a-w
> > > > hat-looks-to-be-a-bug-in-systemd-233/
> > > 
> > > Did you file a bug (against Fedora)?  Can you reproduce with
> > > their
> > > policy?
> > 
> > Not yet i was hoping that some one on IRC or whatever was able to
> > produce it, should be pretty simple to do:
> > 
> > 1. use systemd v233 and/or Fedora 26
> > 2. add a auditallow rule like this: (auditallow domain
> > systemd_unit_file_type (service (enable disable)))
> > 3. disable and enable some service units to see if the check is
> > triggered
> 
> I don't see any USER_AVC messages produced by that on F26 (systemd
> 233)
> or F25 (systemd 231).  I do see them on CentOS 7.3 (systemd 119). 
> Looks like a regression in systemd.

Is this due to the following change:
https://github.com/systemd/systemd/commit/8faae625dc9b6322db452937f54176e56e65265a

If so, then that goes back to systemd v225, and affects Fedora 24 and
later.

Re: run_init messes up terminal settings

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 12159 bytes --]

On Mon, Jun 26, 2017 at 03:00:31PM -0400, Stephen Smalley wrote:
> On Mon, 2017-06-26 at 14:24 -0400, Stephen Smalley wrote:
> > On Mon, 2017-06-26 at 19:49 +0200, Dominick Grift wrote:
> > > On Mon, Jun 26, 2017 at 01:41:05PM -0400, Stephen Smalley wrote:
> > > > On Mon, 2017-06-26 at 19:20 +0200, Dominick Grift wrote:
> > > > > On Mon, Jun 26, 2017 at 01:22:41PM -0400, Stephen Smalley
> > > > > wrote:
> > > > > > On Mon, 2017-06-26 at 18:45 +0200, Dominick Grift wrote:
> > > > > > > On Mon, Jun 26, 2017 at 11:50:10AM -0400, Stephen Smalley
> > > > > > > wrote:
> > > > > > > > On Mon, 2017-06-26 at 15:26 +0200, Dominick Grift wrote:
> > > > > > > > > On Mon, Jun 26, 2017 at 09:08:16AM -0400, Stephen
> > > > > > > > > Smalley
> > > > > > > > > wrote:
> > > > > > > > > > On Sat, 2017-06-24 at 12:20 +0200, Laurent Bigonville
> > > > > > > > > > wrote:
> > > > > > > > > > > Hello,
> > > > > > > > > > > Russell opened the following bug regarding run_init
> > > > > > > > > > > in
> > > > > > > > > > > the
> > > > > > > > > > > debian
> > > > > > > > > > > bts:
> > > > > > > > > > > ====
> > > > > > > > > > > [...]
> > > > > > > > > > > It turns out that the problem was not running
> > > > > > > > > > > $(arch),
> > > > > > > > > > > but
> > > > > > > > > > > running
> > > > > > > > > > > run_init in 
> > > > > > > > > > > the shell it spawned.  Below is an example of
> > > > > > > > > > > reproducing
> > > > > > > > > > > this,
> > > > > > > > > > > the
> > > > > > > > > > > first time 
> > > > > > > > > > > run_init performs as expected.  The second time is
> > > > > > > > > > > fails
> > > > > > > > > > > without
> > > > > > > > > > > me
> > > > > > > > > > > even 
> > > > > > > > > > > typing a password or pressing ENTER.  The result is
> > > > > > > > > > > the
> > > > > > > > > > > same
> > > > > > > > > > > with
> > > > > > > > > > > any
> > > > > > > > > > > command, 
> > > > > > > > > > > but ls is just a good example.  This happens no
> > > > > > > > > > > matter
> > > > > > > > > > > what
> > > > > > > > > > > shell
> > > > > > > > > > > is
> > > > > > > > > > > spawned 
> > > > > > > > > > > (whether it's ssh, su, or just an Xterm), run_init
> > > > > > > > > > > seems
> > > > > > > > > > > generally
> > > > > > > > > > > broken with 
> > > > > > > > > > > the 4.9.0-2-amd64/4.9.13-1 kernel at least.
> > > > > > > > > > > 
> > > > > > > > > > > NB I can't rule out the possibility of a kernel bug
> > > > > > > > > > > at
> > > > > > > > > > > this
> > > > > > > > > > > stage.  But at 
> > > > > > > > > > > this time it seems best to assume it's a run_init
> > > > > > > > > > > bug
> > > > > > > > > > > until
> > > > > > > > > > > proven
> > > > > > > > > > > otherwise.
> > > > > > > > > > > 
> > > > > > > > > > > Sorry for the inconvenience Andreas.
> > > > > > > > > > > 
> > > > > > > > > > > # run_init ls /boot
> > > > > > > > > > > Authenticating root.
> > > > > > > > > > > Password: 
> > > > > > > > > > > config-4.9.0-2-
> > > > > > > > > > > amd64      lost+found                System.map-
> > > > > > > > > > > 4.9.0-
> > > > > > > > > > > 3-amd64
> > > > > > > > > > > config-4.9.0-3-
> > > > > > > > > > > amd64      memtest86+.bin            vmlinuz-
> > > > > > > > > > > 4.9.0-2-
> > > > > > > > > > > amd64
> > > > > > > > > > > grub                      memtest86+_multiboot.bin 
> > > > > > > > > > >  v
> > > > > > > > > > > mlin
> > > > > > > > > > > uz-
> > > > > > > > > > > 4.9.0-3-
> > > > > > > > > > > amd64
> > > > > > > > > > > initrd.img-4.9.0-2-amd64  real
> > > > > > > > > > > initrd.img-4.9.0-3-amd64  System.map-4.9.0-2-amd64
> > > > > > > > > > > # run_init ls /boot
> > > > > > > > > > > Authenticating root.
> > > > > > > > > > > Password: 
> > > > > > > > > > > run_init: incorrect password for root
> > > > > > > > > > > authentication failed.
> > > > > > > > > > > # 
> > > > > > > > > > > ====
> > > > > > > > > > > I can reproduce this with 2.7-rc3, run_init is
> > > > > > > > > > > compiled
> > > > > > > > > > > with
> > > > > > > > > > > pam
> > > > > > > > > > > and
> > > > > > > > > > > audit support.
> > > > > > > > > > > An idea what could happen here?
> > > > > > > > > > > Regards,
> > > > > > > > > > > Laurent Bigonville
> > > > > > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=8
> > > > > > > > > > > 63
> > > > > > > > > > > 187
> > > > > > > > > > 
> > > > > > > > > > I don't think this could have ever worked under
> > > > > > > > > > run_init
> > > > > > > > > > since
> > > > > > > > > > open_init_pty was introduced (originally from
> > > > > > > > > > Debian);
> > > > > > > > > > note
> > > > > > > > > > that
> > > > > > > > > > open_init_pty does alter terminal settings.
> > > > > > > > > > 
> > > > > > > > > > I don't quite follow the example given above.  It
> > > > > > > > > > shows
> > > > > > > > > > executing
> > > > > > > > > > run_init twice with ls /boot as the arguments, which
> > > > > > > > > > is
> > > > > > > > > > not
> > > > > > > > > > running
> > > > > > > > > > run_init within run_init.  That works fine for me.
> > > > > > > > > > 
> > > > > > > > > > If I try something like:
> > > > > > > > > > run_init run_init ls /boot
> > > > > > > > > > which actually runs run_init within run_init, then
> > > > > > > > > > that
> > > > > > > > > > also
> > > > > > > > > > works
> > > > > > > > > > for
> > > > > > > > > > me without problem.
> > > > > > > > > > 
> > > > > > > > > > If I try something like:
> > > > > > > > > > run_init /bin/bash
> > > > > > > > > > then I lose any echoing of input characters to the
> > > > > > > > > > shell
> > > > > > > > > > (due
> > > > > > > > > > to
> > > > > > > > > > open_init_pty turning it off), but I can enter
> > > > > > > > > > commands
> > > > > > > > > > and
> > > > > > > > > > execute
> > > > > > > > > > them, or run stty sane to regain echoing.  But I
> > > > > > > > > > don't
> > > > > > > > > > think
> > > > > > > > > > that
> > > > > > > > > > has
> > > > > > > > > > ever been supported since the introduction of
> > > > > > > > > > open_init_pty
> > > > > > > > > > in
> > > > > > > > > > 2005
> > > > > > > > > > (policycoreutils 1.21.2).  What's the use case for
> > > > > > > > > > it?
> > > > > > > > > > 
> > > > > > > > > > Side bar: run_init (and open_init_pty) are no longer
> > > > > > > > > > packaged
> > > > > > > > > > by
> > > > > > > > > > Fedora
> > > > > > > > > > since systemd renders it unnecessary, and even prior
> > > > > > > > > > to
> > > > > > > > > > that,
> > > > > > > > > > Fedora
> > > > > > > > > > policy enabled DIRECT_INITRC=y in build.conf, and
> > > > > > > > > > therefore
> > > > > > > > > > run_init
> > > > > > > > > 
> > > > > > > > > Correct me if i am wrong but fedora has DIRECT_INITRC=n
> > > > > > > > > AFAICT
> > > > > > > > > 
> > > > > > > > > https://src.fedoraproject.org/cgit/rpms/selinux-policy.
> > > > > > > > > gi
> > > > > > > > > t/tr
> > > > > > > > > ee/s
> > > > > > > > > elin
> > > > > > > > > ux-policy.spec#n173
> > > > > > > > > https://src.fedoraproject.org/cgit/rpms/selinux-policy.
> > > > > > > > > gi
> > > > > > > > > t/tr
> > > > > > > > > ee/s
> > > > > > > > > elin
> > > > > > > > > ux-policy.spec#n393
> > > > > > > > > 
> > > > > > > > > I vaguely recall that in a strict environment one still
> > > > > > > > > might
> > > > > > > > > need
> > > > > > > > > run_init for the `update aliases` functionality in
> > > > > > > > > redhar-
> > > > > > > > > based
> > > > > > > > > distributions.. i might be wrong though
> > > > > > > > 
> > > > > > > > run_init is no longer packaged in Fedora at all (see
> > > > > > > > policycoreutils.spec, which removes it during %install so
> > > > > > > > that
> > > > > > > > it
> > > > > > > > will
> > > > > > > > not be packaged).  Looking at the ChangeLog, this
> > > > > > > > happened
> > > > > > > > in
> > > > > > > > 2012:
> > > > > > > > * Mon Nov 5 2012 Dan Walsh <dwalsh@redhat.com> - 2.1.12-
> > > > > > > > 25
> > > > > > > > - Remove run_init, no longer needed with systemd.
> > > > > > > > 
> > > > > > > > Thus, DIRECT_INITRC=y is no longer required either, for
> > > > > > > > the
> > > > > > > > same
> > > > > > > > reason
> > > > > > > > (obsoleted by systemd).  Prior to that change, Fedora
> > > > > > > > built
> > > > > > > > with
> > > > > > > > DIRECT_INITRC=y for -targeted policy; only -mls and
> > > > > > > > -strict
> > > > > > > > built
> > > > > > > > with
> > > > > > > > DIRECT_INITRC=n and needed run_init.
> > > > > > > 
> > > > > > > Maybe, I recall that previously Fedora use to hack around
> > > > > > > DIRECT_INITRC with unconfined_t but AFAICR it always
> > > > > > > applied
> > > > > > > to
> > > > > > > sysadm_t.
> > > > > > > Does not make any difference though. However I do, kind of,
> > > > > > > wonder if
> > > > > > > sysadm_t is currently able to update the aliases db with
> > > > > > > sendmail
> > > > > > > (but then again it has been a long time since redhat
> > > > > > > shipped
> > > > > > > with
> > > > > > > sendmail enabled by default)
> > > > > > > 
> > > > > > > Nevertheless, gentoo relies on run_init for openrc, and in
> > > > > > > debian
> > > > > > > systemd is optional (i think)
> > > > > > > 
> > > > > > > Normally I am all for removing as much as possible, but
> > > > > > > with
> > > > > > > run_init
> > > > > > > I have mixed feelings, because systemd has been and is a
> > > > > > > headache
> > > > > > > IMHO
> > > > > > > 
> > > > > > > No one was able to confirm it but last lime i tried the
> > > > > > > "service
> > > > > > > enable/disable" access vector was broken. Atleast with good
> > > > > > > old
> > > > > > > sysvinit/upstart we didnt have to depend selinux extension
> > > > > > > code
> > > > > > > to be
> > > > > > > able to control this as it was all transparent.
> > > > > > 
> > > > > > You'll have to clarify what you mean by "broken" here,
> > > > > > preferably
> > > > > > with
> > > > > > a reproducer.
> > > > > > 
> > > > > 
> > > > > In fedora 26 i noticed that the "service disable/enable" checks
> > > > > were
> > > > > no longer performed.
> > > > > 
> > > > > In other words confined administrators were able to
> > > > > disable/enable
> > > > > arbitrary service units.
> > > > > 
> > > > > https://tfirg.undo.it/wordpress/dssp2-confined-administrators-a
> > > > > nd
> > > > > -a-w
> > > > > hat-looks-to-be-a-bug-in-systemd-233/
> > > > 
> > > > Did you file a bug (against Fedora)?  Can you reproduce with
> > > > their
> > > > policy?
> > > 
> > > Not yet i was hoping that some one on IRC or whatever was able to
> > > produce it, should be pretty simple to do:
> > > 
> > > 1. use systemd v233 and/or Fedora 26
> > > 2. add a auditallow rule like this: (auditallow domain
> > > systemd_unit_file_type (service (enable disable)))
> > > 3. disable and enable some service units to see if the check is
> > > triggered
> > 
> > I don't see any USER_AVC messages produced by that on F26 (systemd
> > 233)
> > or F25 (systemd 231).  I do see them on CentOS 7.3 (systemd 119). 
> > Looks like a regression in systemd.
> 
> Is this due to the following change:
> https://github.com/systemd/systemd/commit/8faae625dc9b6322db452937f54176e56e65265a
> 
> If so, then that goes back to systemd v225, and affects Fedora 24 and
> later.
> 
> 

I do not know what to say. No point in filing the issue because there is no one to tackle this anyway.
The systemd people are only "SELinux gurus" when it comes to removing SELinux code (after they adopt it) but not when it comes to adding a line of SELinux code; then they refuse claiming they are no "SELinux guru"
The author of this code abandoned ship ... so I guess we'll have to make do

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: run_init messes up terminal settings

[Stephen Smalley]

On Mon, 2017-06-26 at 21:16 +0200, Dominick Grift wrote:
> On Mon, Jun 26, 2017 at 03:00:31PM -0400, Stephen Smalley wrote:
> > On Mon, 2017-06-26 at 14:24 -0400, Stephen Smalley wrote:
> > > On Mon, 2017-06-26 at 19:49 +0200, Dominick Grift wrote:
> > > > On Mon, Jun 26, 2017 at 01:41:05PM -0400, Stephen Smalley
> > > > wrote:
> > > > > On Mon, 2017-06-26 at 19:20 +0200, Dominick Grift wrote:
> > > > > > On Mon, Jun 26, 2017 at 01:22:41PM -0400, Stephen Smalley
> > > > > > wrote:
> > > > > > > On Mon, 2017-06-26 at 18:45 +0200, Dominick Grift wrote:
> > > > > > > > On Mon, Jun 26, 2017 at 11:50:10AM -0400, Stephen
> > > > > > > > Smalley
> > > > > > > > wrote:
> > > > > > > > > On Mon, 2017-06-26 at 15:26 +0200, Dominick Grift
> > > > > > > > > wrote:
> > > > > > > > > > On Mon, Jun 26, 2017 at 09:08:16AM -0400, Stephen
> > > > > > > > > > Smalley
> > > > > > > > > > wrote:
> > > > > > > > > > > On Sat, 2017-06-24 at 12:20 +0200, Laurent
> > > > > > > > > > > Bigonville
> > > > > > > > > > > wrote:
> > > > > > > > > > > > Hello,
> > > > > > > > > > > > Russell opened the following bug regarding
> > > > > > > > > > > > run_init
> > > > > > > > > > > > in
> > > > > > > > > > > > the
> > > > > > > > > > > > debian
> > > > > > > > > > > > bts:
> > > > > > > > > > > > ====
> > > > > > > > > > > > [...]
> > > > > > > > > > > > It turns out that the problem was not running
> > > > > > > > > > > > $(arch),
> > > > > > > > > > > > but
> > > > > > > > > > > > running
> > > > > > > > > > > > run_init in 
> > > > > > > > > > > > the shell it spawned.  Below is an example of
> > > > > > > > > > > > reproducing
> > > > > > > > > > > > this,
> > > > > > > > > > > > the
> > > > > > > > > > > > first time 
> > > > > > > > > > > > run_init performs as expected.  The second time
> > > > > > > > > > > > is
> > > > > > > > > > > > fails
> > > > > > > > > > > > without
> > > > > > > > > > > > me
> > > > > > > > > > > > even 
> > > > > > > > > > > > typing a password or pressing ENTER.  The
> > > > > > > > > > > > result is
> > > > > > > > > > > > the
> > > > > > > > > > > > same
> > > > > > > > > > > > with
> > > > > > > > > > > > any
> > > > > > > > > > > > command, 
> > > > > > > > > > > > but ls is just a good example.  This happens no
> > > > > > > > > > > > matter
> > > > > > > > > > > > what
> > > > > > > > > > > > shell
> > > > > > > > > > > > is
> > > > > > > > > > > > spawned 
> > > > > > > > > > > > (whether it's ssh, su, or just an Xterm),
> > > > > > > > > > > > run_init
> > > > > > > > > > > > seems
> > > > > > > > > > > > generally
> > > > > > > > > > > > broken with 
> > > > > > > > > > > > the 4.9.0-2-amd64/4.9.13-1 kernel at least.
> > > > > > > > > > > > 
> > > > > > > > > > > > NB I can't rule out the possibility of a kernel
> > > > > > > > > > > > bug
> > > > > > > > > > > > at
> > > > > > > > > > > > this
> > > > > > > > > > > > stage.  But at 
> > > > > > > > > > > > this time it seems best to assume it's a
> > > > > > > > > > > > run_init
> > > > > > > > > > > > bug
> > > > > > > > > > > > until
> > > > > > > > > > > > proven
> > > > > > > > > > > > otherwise.
> > > > > > > > > > > > 
> > > > > > > > > > > > Sorry for the inconvenience Andreas.
> > > > > > > > > > > > 
> > > > > > > > > > > > # run_init ls /boot
> > > > > > > > > > > > Authenticating root.
> > > > > > > > > > > > Password: 
> > > > > > > > > > > > config-4.9.0-2-
> > > > > > > > > > > > amd64      lost+found                System.map
> > > > > > > > > > > > -
> > > > > > > > > > > > 4.9.0-
> > > > > > > > > > > > 3-amd64
> > > > > > > > > > > > config-4.9.0-3-
> > > > > > > > > > > > amd64      memtest86+.bin            vmlinuz-
> > > > > > > > > > > > 4.9.0-2-
> > > > > > > > > > > > amd64
> > > > > > > > > > > > grub                      memtest86+_multiboot.
> > > > > > > > > > > > bin 
> > > > > > > > > > > >  v
> > > > > > > > > > > > mlin
> > > > > > > > > > > > uz-
> > > > > > > > > > > > 4.9.0-3-
> > > > > > > > > > > > amd64
> > > > > > > > > > > > initrd.img-4.9.0-2-amd64  real
> > > > > > > > > > > > initrd.img-4.9.0-3-amd64  System.map-4.9.0-2-
> > > > > > > > > > > > amd64
> > > > > > > > > > > > # run_init ls /boot
> > > > > > > > > > > > Authenticating root.
> > > > > > > > > > > > Password: 
> > > > > > > > > > > > run_init: incorrect password for root
> > > > > > > > > > > > authentication failed.
> > > > > > > > > > > > # 
> > > > > > > > > > > > ====
> > > > > > > > > > > > I can reproduce this with 2.7-rc3, run_init is
> > > > > > > > > > > > compiled
> > > > > > > > > > > > with
> > > > > > > > > > > > pam
> > > > > > > > > > > > and
> > > > > > > > > > > > audit support.
> > > > > > > > > > > > An idea what could happen here?
> > > > > > > > > > > > Regards,
> > > > > > > > > > > > Laurent Bigonville
> > > > > > > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?b
> > > > > > > > > > > > ug=8
> > > > > > > > > > > > 63
> > > > > > > > > > > > 187
> > > > > > > > > > > 
> > > > > > > > > > > I don't think this could have ever worked under
> > > > > > > > > > > run_init
> > > > > > > > > > > since
> > > > > > > > > > > open_init_pty was introduced (originally from
> > > > > > > > > > > Debian);
> > > > > > > > > > > note
> > > > > > > > > > > that
> > > > > > > > > > > open_init_pty does alter terminal settings.
> > > > > > > > > > > 
> > > > > > > > > > > I don't quite follow the example given above.  It
> > > > > > > > > > > shows
> > > > > > > > > > > executing
> > > > > > > > > > > run_init twice with ls /boot as the arguments,
> > > > > > > > > > > which
> > > > > > > > > > > is
> > > > > > > > > > > not
> > > > > > > > > > > running
> > > > > > > > > > > run_init within run_init.  That works fine for
> > > > > > > > > > > me.
> > > > > > > > > > > 
> > > > > > > > > > > If I try something like:
> > > > > > > > > > > run_init run_init ls /boot
> > > > > > > > > > > which actually runs run_init within run_init,
> > > > > > > > > > > then
> > > > > > > > > > > that
> > > > > > > > > > > also
> > > > > > > > > > > works
> > > > > > > > > > > for
> > > > > > > > > > > me without problem.
> > > > > > > > > > > 
> > > > > > > > > > > If I try something like:
> > > > > > > > > > > run_init /bin/bash
> > > > > > > > > > > then I lose any echoing of input characters to
> > > > > > > > > > > the
> > > > > > > > > > > shell
> > > > > > > > > > > (due
> > > > > > > > > > > to
> > > > > > > > > > > open_init_pty turning it off), but I can enter
> > > > > > > > > > > commands
> > > > > > > > > > > and
> > > > > > > > > > > execute
> > > > > > > > > > > them, or run stty sane to regain echoing.  But I
> > > > > > > > > > > don't
> > > > > > > > > > > think
> > > > > > > > > > > that
> > > > > > > > > > > has
> > > > > > > > > > > ever been supported since the introduction of
> > > > > > > > > > > open_init_pty
> > > > > > > > > > > in
> > > > > > > > > > > 2005
> > > > > > > > > > > (policycoreutils 1.21.2).  What's the use case
> > > > > > > > > > > for
> > > > > > > > > > > it?
> > > > > > > > > > > 
> > > > > > > > > > > Side bar: run_init (and open_init_pty) are no
> > > > > > > > > > > longer
> > > > > > > > > > > packaged
> > > > > > > > > > > by
> > > > > > > > > > > Fedora
> > > > > > > > > > > since systemd renders it unnecessary, and even
> > > > > > > > > > > prior
> > > > > > > > > > > to
> > > > > > > > > > > that,
> > > > > > > > > > > Fedora
> > > > > > > > > > > policy enabled DIRECT_INITRC=y in build.conf, and
> > > > > > > > > > > therefore
> > > > > > > > > > > run_init
> > > > > > > > > > 
> > > > > > > > > > Correct me if i am wrong but fedora has
> > > > > > > > > > DIRECT_INITRC=n
> > > > > > > > > > AFAICT
> > > > > > > > > > 
> > > > > > > > > > https://src.fedoraproject.org/cgit/rpms/selinux-pol
> > > > > > > > > > icy.
> > > > > > > > > > gi
> > > > > > > > > > t/tr
> > > > > > > > > > ee/s
> > > > > > > > > > elin
> > > > > > > > > > ux-policy.spec#n173
> > > > > > > > > > https://src.fedoraproject.org/cgit/rpms/selinux-pol
> > > > > > > > > > icy.
> > > > > > > > > > gi
> > > > > > > > > > t/tr
> > > > > > > > > > ee/s
> > > > > > > > > > elin
> > > > > > > > > > ux-policy.spec#n393
> > > > > > > > > > 
> > > > > > > > > > I vaguely recall that in a strict environment one
> > > > > > > > > > still
> > > > > > > > > > might
> > > > > > > > > > need
> > > > > > > > > > run_init for the `update aliases` functionality in
> > > > > > > > > > redhar-
> > > > > > > > > > based
> > > > > > > > > > distributions.. i might be wrong though
> > > > > > > > > 
> > > > > > > > > run_init is no longer packaged in Fedora at all (see
> > > > > > > > > policycoreutils.spec, which removes it during
> > > > > > > > > %install so
> > > > > > > > > that
> > > > > > > > > it
> > > > > > > > > will
> > > > > > > > > not be packaged).  Looking at the ChangeLog, this
> > > > > > > > > happened
> > > > > > > > > in
> > > > > > > > > 2012:
> > > > > > > > > * Mon Nov 5 2012 Dan Walsh <dwalsh@redhat.com> -
> > > > > > > > > 2.1.12-
> > > > > > > > > 25
> > > > > > > > > - Remove run_init, no longer needed with systemd.
> > > > > > > > > 
> > > > > > > > > Thus, DIRECT_INITRC=y is no longer required either,
> > > > > > > > > for
> > > > > > > > > the
> > > > > > > > > same
> > > > > > > > > reason
> > > > > > > > > (obsoleted by systemd).  Prior to that change, Fedora
> > > > > > > > > built
> > > > > > > > > with
> > > > > > > > > DIRECT_INITRC=y for -targeted policy; only -mls and
> > > > > > > > > -strict
> > > > > > > > > built
> > > > > > > > > with
> > > > > > > > > DIRECT_INITRC=n and needed run_init.
> > > > > > > > 
> > > > > > > > Maybe, I recall that previously Fedora use to hack
> > > > > > > > around
> > > > > > > > DIRECT_INITRC with unconfined_t but AFAICR it always
> > > > > > > > applied
> > > > > > > > to
> > > > > > > > sysadm_t.
> > > > > > > > Does not make any difference though. However I do, kind
> > > > > > > > of,
> > > > > > > > wonder if
> > > > > > > > sysadm_t is currently able to update the aliases db
> > > > > > > > with
> > > > > > > > sendmail
> > > > > > > > (but then again it has been a long time since redhat
> > > > > > > > shipped
> > > > > > > > with
> > > > > > > > sendmail enabled by default)
> > > > > > > > 
> > > > > > > > Nevertheless, gentoo relies on run_init for openrc, and
> > > > > > > > in
> > > > > > > > debian
> > > > > > > > systemd is optional (i think)
> > > > > > > > 
> > > > > > > > Normally I am all for removing as much as possible, but
> > > > > > > > with
> > > > > > > > run_init
> > > > > > > > I have mixed feelings, because systemd has been and is
> > > > > > > > a
> > > > > > > > headache
> > > > > > > > IMHO
> > > > > > > > 
> > > > > > > > No one was able to confirm it but last lime i tried the
> > > > > > > > "service
> > > > > > > > enable/disable" access vector was broken. Atleast with
> > > > > > > > good
> > > > > > > > old
> > > > > > > > sysvinit/upstart we didnt have to depend selinux
> > > > > > > > extension
> > > > > > > > code
> > > > > > > > to be
> > > > > > > > able to control this as it was all transparent.
> > > > > > > 
> > > > > > > You'll have to clarify what you mean by "broken" here,
> > > > > > > preferably
> > > > > > > with
> > > > > > > a reproducer.
> > > > > > > 
> > > > > > 
> > > > > > In fedora 26 i noticed that the "service disable/enable"
> > > > > > checks
> > > > > > were
> > > > > > no longer performed.
> > > > > > 
> > > > > > In other words confined administrators were able to
> > > > > > disable/enable
> > > > > > arbitrary service units.
> > > > > > 
> > > > > > https://tfirg.undo.it/wordpress/dssp2-confined-administrato
> > > > > > rs-a
> > > > > > nd
> > > > > > -a-w
> > > > > > hat-looks-to-be-a-bug-in-systemd-233/
> > > > > 
> > > > > Did you file a bug (against Fedora)?  Can you reproduce with
> > > > > their
> > > > > policy?
> > > > 
> > > > Not yet i was hoping that some one on IRC or whatever was able
> > > > to
> > > > produce it, should be pretty simple to do:
> > > > 
> > > > 1. use systemd v233 and/or Fedora 26
> > > > 2. add a auditallow rule like this: (auditallow domain
> > > > systemd_unit_file_type (service (enable disable)))
> > > > 3. disable and enable some service units to see if the check is
> > > > triggered
> > > 
> > > I don't see any USER_AVC messages produced by that on F26
> > > (systemd
> > > 233)
> > > or F25 (systemd 231).  I do see them on CentOS 7.3 (systemd
> > > 119). 
> > > Looks like a regression in systemd.
> > 
> > Is this due to the following change:
> > https://github.com/systemd/systemd/commit/8faae625dc9b6322db452937f
> > 54176e56e65265a
> > 
> > If so, then that goes back to systemd v225, and affects Fedora 24
> > and
> > later.
> > 
> > 
> 
> I do not know what to say. No point in filing the issue because there
> is no one to tackle this anyway.
> The systemd people are only "SELinux gurus" when it comes to removing
> SELinux code (after they adopt it) but not when it comes to adding a
> line of SELinux code; then they refuse claiming they are no "SELinux
> guru"
> The author of this code abandoned ship ... so I guess we'll have to
> make do

There is already an (old) systemd issue for it - 1050, cited by the
aforementioned commit (and on which you commented originally).  But it
would probably help to open a bug against Fedora for it and add the
Fedora SELinux folks to it.  If that fails to get any traction, then
open an issue in the selinux github project so that it doesn't get lost
and maybe I or someone else will fix it someday.

Re: run_init messes up terminal settings

[Russell Coker]

On Monday, 26 June 2017 11:22:31 AM AEST Stephen Smalley wrote:
> I'd be inclined to just drop open_init_pty (for that matter, I'd like
> to deprecate/drop run_init entirely, but I guess it might be needed if
> not using DIRECT_INITRC=y and not using systemd).

Currently for my use (which involves more strict configurations than most 
Debian users have) the only use of run_init is for running newaliases on a 
Postfix system and for any dpkg commands relating to Postfix (which end up 
running newaliases in the postinst).

The alternative to this is to allow sendmail when run from an unconfined_t or 
sysadm_t shell the ability to write to etc_aliases_t.

Given the problems with run_init and the lack of use of it it seems that 
changing the policy to give slightly more access to sendmail would make sense.

Currently we have user_mail_t as the domain for sendmail when run from 
unconfined_t and user_t.  We need to either have separate domains for this or 
rely on constraints to prevent a user_r session from writing to etc_aliases_t.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/