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@xxxxxxxxxx> - 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.
