Bug#1023850: do not require dbus, use default-dbus-system-bus | dbus-system-bus
Package: rtkit Version: 0.13-4+b1 rtkit currently depends on package dbus. This package pulls in package dbus-daemon. this behavior is not desired on systems that use package dbus-broker instead of package dbus-daemon. see package policykit-1 for an example of how to depend on either dbus-daemon or dbus-broker depending on what is used. -- gpg --locate-keys dominick.gr...@defensec.nl Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 Dominick Grift
Bug#1020213: libatk1.0 pulls in at-spi2-core
Package: libatk1.0-0 Version: 2.46.0-1 libatk1.0-0 (2.46.0-1) pulls in at-spi2-core (and gsettings-desktop-schemas). It would be really nice if we could opt out of at-spi2-core. at-spi2-core is very intrusive and by itself it does not add any value. root@brutus:~# apt-get full-upgrade --dry-run Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done The following package was automatically installed and is no longer required: libatk1.0-data Use 'apt autoremove' to remove it. The following NEW packages will be installed: at-spi2-core The following packages will be upgraded: libatk1.0-0 1 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Inst at-spi2-core (2.46.0-1 Debian:unstable [amd64]) Inst libatk1.0-0 [2.38.0-1] (2.46.0-1 Debian:unstable [amd64]) Conf at-spi2-core (2.46.0-1 Debian:unstable [amd64]) Conf libatk1.0-0 (2.46.0-1 Debian:unstable [amd64]) -- gpg --locate-keys dominick.gr...@defensec.nl Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 Dominick Grift
Bug#943413: sudo 1.8.28p1-1 built with wrong libexecdir
On Thu, Oct 24, 2019 at 02:32:32PM -0600, Bdale Garbee wrote: > tags 943313 +pending > thanks Thanks. I did you mean to use strong language but this does break sudo 1.2.28p1 in some scenario's It will be looking for /usr/lib/sudo/sudo/sesh, and it will not be able to find it. Sudo functionality relying in `sesh` will not work. > > Dominick Grift writes: > > > Package: sudo > > Version: 1.8.28p1-1 > > > > The --libexecdir=/usr/lib/sudo entries in debian/rules are wrong > > > > It should be --libexecdir=/usr/lib > > The word "wrong" might be a bit strong, but I agree that losing the > extra directory level makes sense. Patched in git for the next upload. > > Bdale -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
Bug#943413: sudo 1.8.28p1-1 built with wrong libexecdir
Package: sudo Version: 1.8.28p1-1 The --libexecdir=/usr/lib/sudo entries in debian/rules are wrong It should be --libexecdir=/usr/lib -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
Bug#878401: [systemd] Dependency on /tmp not correctly stated for some sound.target (or /tmp/pulse-* shows up underneath my /tmp mount)
On Sun, Sep 22, 2019 at 05:40:14PM +0200, Dominick Grift wrote:
> Setting PULSE_RUNTIME_PATH did not do it for me.
>
> I borrowed the following from Fedora, and did:
>
> 1. /etc/udev/rules.d/90-alsa-restore.rules:
>
> ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*",
> GOTO="alsa_restore_go"
> GOTO="alsa_restore_end"
>
> LABEL="alsa_restore_go"
> TEST!="/etc/alsa/state-daemon.conf", RUN+="/usr/sbin/alsactl -E
> HOME=/run/alsa -E ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf
> --initfile=/usr/share/alsa/init/00main restore /dev/$name"
> TEST=="/etc/alsa/state-daemon.conf", RUN+="/usr/sbin/alsactl -E
> HOME=/run/alsa -E ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf
> --initfile=/usr/share/alsa/init/00main nrestore /dev/$name"
>
> LABEL="alsa_restore_end"
>
> 2. /etc/systemd/system/alsa-state.service:
>
> #
> # Note that two different ALSA card state management schemes exist and they
> # can be switched using a file exist check - /etc/alsa/state-daemon.conf .
> #
>
> [Unit]
> Description=Manage Sound Card State (restore and store)
> Documentation=man:alsactl(1)
> ConditionPathExists=/etc/alsa/state-daemon.conf
>
> [Service]
> Type=simple
> ExecStart=-/usr/sbin/alsactl -E HOME=/run/alsa -E
> ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf
> --initfile=/usr/share/alsa/init/00main -s -n 19 -c rdaemon
> ExecStop=-/usr/sbin/alsactl -E HOME=/run/alsa -s kill save_and_quit
>
> 3. /etc/systemd/system/alsa-restore.service:
>
> #
> # Note that two different ALSA card state management schemes exist and they
> # can be switched using a file exist check - /etc/alsa/state-daemon.conf .
> #
>
> [Unit]
> Description=Save/Restore Sound Card State
> Documentation=man:alsactl(1)
> ConditionPathExists=!/etc/alsa/state-daemon.conf
>
> [Service]
> Type=oneshot
> RemainAfterExit=true
> ExecStart=-/usr/sbin/alsactl -E HOME=/run/alsa -E
> ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf
> --initfile=/usr/share/alsa/init/00main restore
> ExecStop=-/usr/sbin/alsactl -E HOME=/run/alsa -E
> ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf store
> StandardOutput=syslog
>
>
> ... seems to work
Oh and:
4. cat /etc/alsa/alsactl.conf:
ctl.hw {
@args [ CARD ]
@args.CARD {
type string
default "0"
}
type hw
card $CARD
}
5. cat /etc/alsa/state-daemon.conf:
# Remove this file to disable the alsactl daemon mode
signature.asc
Description: PGP signature
Bug#878401: [systemd] Dependency on /tmp not correctly stated for some sound.target (or /tmp/pulse-* shows up underneath my /tmp mount)
Setting PULSE_RUNTIME_PATH did not do it for me. I borrowed the following from Fedora, and did: 1. /etc/udev/rules.d/90-alsa-restore.rules: ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", GOTO="alsa_restore_go" GOTO="alsa_restore_end" LABEL="alsa_restore_go" TEST!="/etc/alsa/state-daemon.conf", RUN+="/usr/sbin/alsactl -E HOME=/run/alsa -E ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf --initfile=/usr/share/alsa/init/00main restore /dev/$name" TEST=="/etc/alsa/state-daemon.conf", RUN+="/usr/sbin/alsactl -E HOME=/run/alsa -E ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf --initfile=/usr/share/alsa/init/00main nrestore /dev/$name" LABEL="alsa_restore_end" 2. /etc/systemd/system/alsa-state.service: # # Note that two different ALSA card state management schemes exist and they # can be switched using a file exist check - /etc/alsa/state-daemon.conf . # [Unit] Description=Manage Sound Card State (restore and store) Documentation=man:alsactl(1) ConditionPathExists=/etc/alsa/state-daemon.conf [Service] Type=simple ExecStart=-/usr/sbin/alsactl -E HOME=/run/alsa -E ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf --initfile=/usr/share/alsa/init/00main -s -n 19 -c rdaemon ExecStop=-/usr/sbin/alsactl -E HOME=/run/alsa -s kill save_and_quit 3. /etc/systemd/system/alsa-restore.service: # # Note that two different ALSA card state management schemes exist and they # can be switched using a file exist check - /etc/alsa/state-daemon.conf . # [Unit] Description=Save/Restore Sound Card State Documentation=man:alsactl(1) ConditionPathExists=!/etc/alsa/state-daemon.conf [Service] Type=oneshot RemainAfterExit=true ExecStart=-/usr/sbin/alsactl -E HOME=/run/alsa -E ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf --initfile=/usr/share/alsa/init/00main restore ExecStop=-/usr/sbin/alsactl -E HOME=/run/alsa -E ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf store StandardOutput=syslog ... seems to work -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
Bug#933858: (no subject)
>From a traditional strict point of view (without unconfined), this is how the >workflow should be: when you login directly as root you should get "sysadm_r:sysadm_t" (which is the strict equivalent to unconfined) when you want an unprivileged user (users in the "adm" group) to have root access with sysadm_r:sysadm_t, you would associate that user with staff_u: useradd -Z staff_u joe staff_u users should be able to transition to sysadm_r:sysadm_t with sudo: sudo -r sysadm_r -t sysadm_t -s or alternatively with newrole/su: newrole -r sysadm_r su unprivileged users that should never have root access should be associated with user_u: useradd -Z user_u jane -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift
Bug#933858: (no subject)
There is some history to all of this. Reference policy is a continuation of the NSA example policy. The NSA example policy was a "strict" policy that aimed to enforce "least privilege". Least privilege means that processes only get the permissions they need to do the job. Much later on after Tresys took over the example policy from NSA and renamed it to reference policy. Red Hat invented the unconfined domain. The early "targeted" Red Hat policy only had unconfined users (there was no sysadm_u/staff_u etc). Later on the Fedora targeted policy got merged with Tresys strict reference policy. The idea was that one could *optionally* allow unconfined domains, confined and unconfined domains *can optionally* live side by side but they werent intended to mingle. You can make today's "targeted" policy "strict" by disabling the unconfined module. sysadm is the confined (least privilege) equivalent to unconfined. In theory that means that sysadm should be able to do pretty much anything that unconfined can do. The difference between the two is that integrity is enforced in sysadm sessions (least privilege is enforced) where there is no integrity (least privilege) in unconfined sessions. Enforcing some integrity in a session that should be able to virtually do anything is impossible, so as sysadm_u you will inevitably notice rought edges. However with work, the situation for sysadm can improve but it will never be perfect. If you so desire then you can give sysadm_u access to unconfined_r. However this was not the intended design. -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift
Bug#933858: (no subject)
This is by design. There is a seperation between confined and unconfined. sysadm_t is the confined equivalent of the unconfined unconfined_t. It is true though that sysadm_t (and the policy in general) is incomplete, and that it needs more attention. You are ofcourse free and encouranged to tailor the policy to your personal requirements. -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift
Bug#929063: Path of a thousand miles starts with a single step.
You should probably present your real question using the proper chanells, instead of beating around the bush to get your foot in the door. Does Debian want to get rid of its SELinux support, yes or no? Regardless of the answer to this question, i do not believe that this patch makes sense. -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift
Bug#849637: [DSE-Dev] Bug#849637: /sys/devices/system/cpu/online SELinux context
On 12/31/2016 12:41 PM, Dominick Grift wrote: > On 12/31/2016 12:38 PM, Dominick Grift wrote: >> On 12/31/2016 11:34 AM, cgzones wrote: >>> Wow! >>> >>> Thank you very much, I was completely unaware of this feature. >>> I did not read any documentation of it on selinuxproject.org or in The >>> SELinux Notebook v4 about it. >>> >>> I got it working via >>> >>> genfscon sysfs /devices/system/cpu/online >>> gen_context(system_u:object_r:cpu_online_t,s0) >>> >>> at >>> https://github.com/cgzones/debian-package-refpolicy/commit/3ba127468436334275398a824260383208ee58b1 >>> >>> One small issue arises for me: >>> I tried to set up the directory '/sys/kernel/debug/tracing' via >>> 'genfscon sysfs /kernel/debug/tracing >>> gen_context(system_u:object_r:tracefs_t,s0)' >>> but is it still labeled initially system_u:object_r:debugfs_t:s0 after >>> boot but seems to change on the first access? I misread, yes i think tracefs is mounted on demand. But this should not be problem because users of tracefs need to be able to traverse debugfs anyway. >> >> you need a genfscon for tracefs, it is mounted on the >> kernel/debug/tracing dir >> >> genfscon tracefs / gen_context() > > Also a word of advice: don't add any fc specs for anything under /sys > > The stuff in there are not files (its a pseudo fs like /proc and proc > also doesnt have fc specs) > >> >>> >>> Example pattern: >>> >>> [...] boot + ssh login >>> root@debianSE:~# restorecon -v -R -n / >>> Warning no default label for /dev/mqueue >>> Warning no default label for /dev/pts/0 >>> Warning no default label for /tmp/.font-unix >>> Warning no default label for /tmp/.XIM-unix >>> Warning no default label for /tmp/.X11-unix >>> Warning no default label for /tmp/.Test-unix >>> Warning no default label for /tmp/.ICE-unix >>> Would relabel /sys/kernel/debug/tracing from >>> system_u:object_r:debugfs_t:s0 to system_u:object_r:tracefs_t:s0 >>> root@debianSE:~# restorecon -v -R -n / >>> Warning no default label for /dev/mqueue >>> Warning no default label for /dev/pts/0 >>> Warning no default label for /tmp/.font-unix >>> Warning no default label for /tmp/.XIM-unix >>> Warning no default label for /tmp/.X11-unix >>> Warning no default label for /tmp/.Test-unix >>> Warning no default label for /tmp/.ICE-unix >>> >>> Why? >>> >>> I think otherwise this bug can be reassigned to refpolicy. >>> >>> Thanks again Dominick >>> Kindly Regards, >>>Christian Göttsche >>> >>> P.s.: >>> The kernel patch is over here: >>> https://github.com/torvalds/linux/commit/8e01472078763ebc1eaea089a1adab75dd982ccd >>> (might be Linux 4.2? plenty enough for me) >>> >>> 2016-12-31 9:43 GMT+01:00 Dominick Grift <dac.overr...@gmail.com>: >>>> On 12/30/2016 10:51 PM, cgzones wrote: >>>>> But isn't genfscon with subcontexts only available on the /proc >>>>> filesystem? >>>> >>>> If your kernel is not too old, then it also work for sysfs >>>> >>>>> >>>>> 2016-12-30 22:18 GMT+01:00 Dominick Grift <dac.overr...@gmail.com>: >>>>>> On Fri, 30 Dec 2016 12:39:05 +0100 Laurent Bigonville <bi...@debian.org> >>>>>> wrote: >>>>>>> reassign 849637 policycoreutils >>>>>>> thanks >>>>>>> >>>>>>> On Thu, 29 Dec 2016 12:36:30 +0100 cgzones <cgzo...@googlemail.com> >>>>>>> wrote: >>>>>>> >>>>>>> > When running a SELinux enabled system /sys/devices/system/cpu/online >>>>>>> > is mislabeled after boot: >>>>>>> > >>>>>>> > root@test1:/root/selinux/policy# restorecon -vv -R -F -n /sys >>>>>>> > Would relabel /sys/devices/system/cpu/online from >>>>>>> > system_u:object_r:sysfs_t:s0 to system_u:object_r:cpu_online_t:s0 >>>>>>> >>>>>>> Not sure why this is assigned to systemd as this is not created by >>>>>>> systemd. >>>>>>> >>>>>>> It's working with sysvinit because the selinux-autorelabel LSB >>>>>>> initscript is explicitly relabeling it during boot. >>>>>>> >&g
Bug#849637: [DSE-Dev] Bug#849637: /sys/devices/system/cpu/online SELinux context
On 12/31/2016 12:38 PM, Dominick Grift wrote: > On 12/31/2016 11:34 AM, cgzones wrote: >> Wow! >> >> Thank you very much, I was completely unaware of this feature. >> I did not read any documentation of it on selinuxproject.org or in The >> SELinux Notebook v4 about it. >> >> I got it working via >> >> genfscon sysfs /devices/system/cpu/online >> gen_context(system_u:object_r:cpu_online_t,s0) >> >> at >> https://github.com/cgzones/debian-package-refpolicy/commit/3ba127468436334275398a824260383208ee58b1 >> >> One small issue arises for me: >> I tried to set up the directory '/sys/kernel/debug/tracing' via >> 'genfscon sysfs /kernel/debug/tracing >> gen_context(system_u:object_r:tracefs_t,s0)' >> but is it still labeled initially system_u:object_r:debugfs_t:s0 after >> boot but seems to change on the first access? > > you need a genfscon for tracefs, it is mounted on the > kernel/debug/tracing dir > > genfscon tracefs / gen_context() Also a word of advice: don't add any fc specs for anything under /sys The stuff in there are not files (its a pseudo fs like /proc and proc also doesnt have fc specs) > >> >> Example pattern: >> >> [...] boot + ssh login >> root@debianSE:~# restorecon -v -R -n / >> Warning no default label for /dev/mqueue >> Warning no default label for /dev/pts/0 >> Warning no default label for /tmp/.font-unix >> Warning no default label for /tmp/.XIM-unix >> Warning no default label for /tmp/.X11-unix >> Warning no default label for /tmp/.Test-unix >> Warning no default label for /tmp/.ICE-unix >> Would relabel /sys/kernel/debug/tracing from >> system_u:object_r:debugfs_t:s0 to system_u:object_r:tracefs_t:s0 >> root@debianSE:~# restorecon -v -R -n / >> Warning no default label for /dev/mqueue >> Warning no default label for /dev/pts/0 >> Warning no default label for /tmp/.font-unix >> Warning no default label for /tmp/.XIM-unix >> Warning no default label for /tmp/.X11-unix >> Warning no default label for /tmp/.Test-unix >> Warning no default label for /tmp/.ICE-unix >> >> Why? >> >> I think otherwise this bug can be reassigned to refpolicy. >> >> Thanks again Dominick >> Kindly Regards, >>Christian Göttsche >> >> P.s.: >> The kernel patch is over here: >> https://github.com/torvalds/linux/commit/8e01472078763ebc1eaea089a1adab75dd982ccd >> (might be Linux 4.2? plenty enough for me) >> >> 2016-12-31 9:43 GMT+01:00 Dominick Grift <dac.overr...@gmail.com>: >>> On 12/30/2016 10:51 PM, cgzones wrote: >>>> But isn't genfscon with subcontexts only available on the /proc filesystem? >>> >>> If your kernel is not too old, then it also work for sysfs >>> >>>> >>>> 2016-12-30 22:18 GMT+01:00 Dominick Grift <dac.overr...@gmail.com>: >>>>> On Fri, 30 Dec 2016 12:39:05 +0100 Laurent Bigonville <bi...@debian.org> >>>>> wrote: >>>>>> reassign 849637 policycoreutils >>>>>> thanks >>>>>> >>>>>> On Thu, 29 Dec 2016 12:36:30 +0100 cgzones <cgzo...@googlemail.com> >>>>>> wrote: >>>>>> >>>>>> > When running a SELinux enabled system /sys/devices/system/cpu/online >>>>>> > is mislabeled after boot: >>>>>> > >>>>>> > root@test1:/root/selinux/policy# restorecon -vv -R -F -n /sys >>>>>> > Would relabel /sys/devices/system/cpu/online from >>>>>> > system_u:object_r:sysfs_t:s0 to system_u:object_r:cpu_online_t:s0 >>>>>> >>>>>> Not sure why this is assigned to systemd as this is not created by >>>>>> systemd. >>>>>> >>>>>> It's working with sysvinit because the selinux-autorelabel LSB >>>>>> initscript is explicitly relabeling it during boot. >>>>>> >>>>>> Under systemd, that initscript is masked by the >>>>>> selinux-autorelabel.service. >>>>>> >>>>>> I was planning to add a tmpfiles for this, but apparently I forgot about >>>>>> it. >>>>>> >>>>>> Reassigning to policycoreutils >>>>>> >>>>>> Laurent Bigonville >>>>> >>>>> you should be able to add a genfscon() in policy for this, provided that >>>>> the kernel is not too old to support that feature >>>>> >>>>> I would avoid the alternative if possible >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 >>>>> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 >>>>> Dominick Grift >>>>> >>>>> >>>>> ___ >>>>> SELinux-devel mailing list >>>>> selinux-de...@lists.alioth.debian.org >>>>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/selinux-devel >>> >>> >>> -- >>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 >>> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 >>> Dominick Grift >>> > > -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: OpenPGP digital signature
Bug#849637: [DSE-Dev] Bug#849637: /sys/devices/system/cpu/online SELinux context
On 12/31/2016 11:34 AM, cgzones wrote: > Wow! > > Thank you very much, I was completely unaware of this feature. > I did not read any documentation of it on selinuxproject.org or in The > SELinux Notebook v4 about it. > > I got it working via > > genfscon sysfs /devices/system/cpu/online > gen_context(system_u:object_r:cpu_online_t,s0) > > at > https://github.com/cgzones/debian-package-refpolicy/commit/3ba127468436334275398a824260383208ee58b1 > > One small issue arises for me: > I tried to set up the directory '/sys/kernel/debug/tracing' via > 'genfscon sysfs /kernel/debug/tracing > gen_context(system_u:object_r:tracefs_t,s0)' > but is it still labeled initially system_u:object_r:debugfs_t:s0 after > boot but seems to change on the first access? you need a genfscon for tracefs, it is mounted on the kernel/debug/tracing dir genfscon tracefs / gen_context() > > Example pattern: > > [...] boot + ssh login > root@debianSE:~# restorecon -v -R -n / > Warning no default label for /dev/mqueue > Warning no default label for /dev/pts/0 > Warning no default label for /tmp/.font-unix > Warning no default label for /tmp/.XIM-unix > Warning no default label for /tmp/.X11-unix > Warning no default label for /tmp/.Test-unix > Warning no default label for /tmp/.ICE-unix > Would relabel /sys/kernel/debug/tracing from > system_u:object_r:debugfs_t:s0 to system_u:object_r:tracefs_t:s0 > root@debianSE:~# restorecon -v -R -n / > Warning no default label for /dev/mqueue > Warning no default label for /dev/pts/0 > Warning no default label for /tmp/.font-unix > Warning no default label for /tmp/.XIM-unix > Warning no default label for /tmp/.X11-unix > Warning no default label for /tmp/.Test-unix > Warning no default label for /tmp/.ICE-unix > > Why? > > I think otherwise this bug can be reassigned to refpolicy. > > Thanks again Dominick > Kindly Regards, >Christian Göttsche > > P.s.: > The kernel patch is over here: > https://github.com/torvalds/linux/commit/8e01472078763ebc1eaea089a1adab75dd982ccd > (might be Linux 4.2? plenty enough for me) > > 2016-12-31 9:43 GMT+01:00 Dominick Grift <dac.overr...@gmail.com>: >> On 12/30/2016 10:51 PM, cgzones wrote: >>> But isn't genfscon with subcontexts only available on the /proc filesystem? >> >> If your kernel is not too old, then it also work for sysfs >> >>> >>> 2016-12-30 22:18 GMT+01:00 Dominick Grift <dac.overr...@gmail.com>: >>>> On Fri, 30 Dec 2016 12:39:05 +0100 Laurent Bigonville <bi...@debian.org> >>>> wrote: >>>>> reassign 849637 policycoreutils >>>>> thanks >>>>> >>>>> On Thu, 29 Dec 2016 12:36:30 +0100 cgzones <cgzo...@googlemail.com> wrote: >>>>> >>>>> > When running a SELinux enabled system /sys/devices/system/cpu/online >>>>> > is mislabeled after boot: >>>>> > >>>>> > root@test1:/root/selinux/policy# restorecon -vv -R -F -n /sys >>>>> > Would relabel /sys/devices/system/cpu/online from >>>>> > system_u:object_r:sysfs_t:s0 to system_u:object_r:cpu_online_t:s0 >>>>> >>>>> Not sure why this is assigned to systemd as this is not created by >>>>> systemd. >>>>> >>>>> It's working with sysvinit because the selinux-autorelabel LSB >>>>> initscript is explicitly relabeling it during boot. >>>>> >>>>> Under systemd, that initscript is masked by the >>>>> selinux-autorelabel.service. >>>>> >>>>> I was planning to add a tmpfiles for this, but apparently I forgot about >>>>> it. >>>>> >>>>> Reassigning to policycoreutils >>>>> >>>>> Laurent Bigonville >>>> >>>> you should be able to add a genfscon() in policy for this, provided that >>>> the kernel is not too old to support that feature >>>> >>>> I would avoid the alternative if possible >>>>> >>>>> >>>> >>>> -- >>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 >>>> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 >>>> Dominick Grift >>>> >>>> >>>> ___ >>>> SELinux-devel mailing list >>>> selinux-de...@lists.alioth.debian.org >>>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/selinux-devel >> >> >> -- >> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 >> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 >> Dominick Grift >> -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: OpenPGP digital signature
Bug#849637: [DSE-Dev] Bug#849637: /sys/devices/system/cpu/online SELinux context
On 12/30/2016 10:51 PM, cgzones wrote: > But isn't genfscon with subcontexts only available on the /proc filesystem? If your kernel is not too old, then it also work for sysfs > > 2016-12-30 22:18 GMT+01:00 Dominick Grift <dac.overr...@gmail.com>: >> On Fri, 30 Dec 2016 12:39:05 +0100 Laurent Bigonville <bi...@debian.org> >> wrote: >>> reassign 849637 policycoreutils >>> thanks >>> >>> On Thu, 29 Dec 2016 12:36:30 +0100 cgzones <cgzo...@googlemail.com> wrote: >>> >>> > When running a SELinux enabled system /sys/devices/system/cpu/online >>> > is mislabeled after boot: >>> > >>> > root@test1:/root/selinux/policy# restorecon -vv -R -F -n /sys >>> > Would relabel /sys/devices/system/cpu/online from >>> > system_u:object_r:sysfs_t:s0 to system_u:object_r:cpu_online_t:s0 >>> >>> Not sure why this is assigned to systemd as this is not created by systemd. >>> >>> It's working with sysvinit because the selinux-autorelabel LSB >>> initscript is explicitly relabeling it during boot. >>> >>> Under systemd, that initscript is masked by the selinux-autorelabel.service. >>> >>> I was planning to add a tmpfiles for this, but apparently I forgot about it. >>> >>> Reassigning to policycoreutils >>> >>> Laurent Bigonville >> >> you should be able to add a genfscon() in policy for this, provided that >> the kernel is not too old to support that feature >> >> I would avoid the alternative if possible >>> >>> >> >> -- >> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 >> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 >> Dominick Grift >> >> >> ___ >> SELinux-devel mailing list >> selinux-de...@lists.alioth.debian.org >> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/selinux-devel -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: OpenPGP digital signature
Bug#849637: /sys/devices/system/cpu/online SELinux context
On Fri, 30 Dec 2016 17:17:24 +0100 cgzones <cgzo...@googlemail.com> wrote: > Hi, > thanks for your response. > I assigned this bug to systemd, cause I did not know any better and > thought the sysfs filesystem is managed by systemd, like /run. > > Btw, /dev/pts/ptmx is also mislabeled: > > root@debianSE:~# restorecon -vv -R -n /dev > Warning no default label for /dev/mqueue > Warning no default label for /dev/pts/0 > Would relabel /dev/pts/ptmx from system_u:object_r:devpts_t:s0 to > system_u:object_r:ptmx_t:s0 > That context spec for /dev/pts/ptmx should probably be dropped and just leave it devpts_t > > Kindly Regards, > Christian Göttsche > > 2016-12-30 12:39 GMT+01:00 Laurent Bigonville <bi...@debian.org>: > > reassign 849637 policycoreutils > > thanks > > > > On Thu, 29 Dec 2016 12:36:30 +0100 cgzones <cgzo...@googlemail.com> wrote: > > > >> When running a SELinux enabled system /sys/devices/system/cpu/online > >> is mislabeled after boot: > >> > >> root@test1:/root/selinux/policy# restorecon -vv -R -F -n /sys > >> Would relabel /sys/devices/system/cpu/online from > >> system_u:object_r:sysfs_t:s0 to system_u:object_r:cpu_online_t:s0 > > > > Not sure why this is assigned to systemd as this is not created by systemd. > > > > It's working with sysvinit because the selinux-autorelabel LSB initscript is > > explicitly relabeling it during boot. > > > > Under systemd, that initscript is masked by the selinux-autorelabel.service. > > > > I was planning to add a tmpfiles for this, but apparently I forgot about it. > > > > Reassigning to policycoreutils > > > > Laurent Bigonville > > -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: OpenPGP digital signature
Bug#849637: /sys/devices/system/cpu/online SELinux context
On Fri, 30 Dec 2016 12:39:05 +0100 Laurent Bigonville <bi...@debian.org> wrote: > reassign 849637 policycoreutils > thanks > > On Thu, 29 Dec 2016 12:36:30 +0100 cgzones <cgzo...@googlemail.com> wrote: > > > When running a SELinux enabled system /sys/devices/system/cpu/online > > is mislabeled after boot: > > > > root@test1:/root/selinux/policy# restorecon -vv -R -F -n /sys > > Would relabel /sys/devices/system/cpu/online from > > system_u:object_r:sysfs_t:s0 to system_u:object_r:cpu_online_t:s0 > > Not sure why this is assigned to systemd as this is not created by systemd. > > It's working with sysvinit because the selinux-autorelabel LSB > initscript is explicitly relabeling it during boot. > > Under systemd, that initscript is masked by the selinux-autorelabel.service. > > I was planning to add a tmpfiles for this, but apparently I forgot about it. > > Reassigning to policycoreutils > > Laurent Bigonville you should be able to add a genfscon() in policy for this, provided that the kernel is not too old to support that feature I would avoid the alternative if possible > > -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: OpenPGP digital signature
Bug#685992: /usr/sbin/update-flashplugin-nonfree: Please restore selinux context after installing files
Let's not compare init scripts with dpkg scripts. The issue at hand here is that dpkg, and dpkg scripts do not install files with the correct context. As a Fedora user, i am not very familiar with dpkg, but i can tell you that rpm, and the rpm script mechanism are SELinux aware. They use the matchpathcon(), and setfscreatecon() libselinux functions to query what the security contexts of a to be installed object should be, and to install objects with the security contexts returned by matchpathcon() using setfscreatecon() or similar libselinux functions. For inspiration, i would suggest one studies the SELinux commits in the rpm repository. If dpkg cannot, because it uses a different mechanism for dpkg script than rpm does for rpm scripts, deal with those scripts in a similar way then a other solution should be thought of. For example create a hook that gets called in dpkg scripts if it is determined that SElinux is enabled on the target system that runs restoreon. The idea is that policy defines/maintains a list with file context specifications, restorecon and matchpathcon commands query hat list to determine what a specified location should be labeled. Restorecon additionally resets the context of a specified location according to what is specified system wide in the file context specifications. So its a one, or two step procedure: prefered (not racy) (see libselinux: http://selinuxproject.org/page/LibselinuxAPISummary ) matchpathcon() object: determine what a specified object should be labeled by querying the system wide file context specifications define by security policy, and or admin setfscreatecon() object (see man setfscreatecon): create the specified object with the context that was returned by the matchpathcon() function. alternate (racy): use the restorecon/setfiles object commands to reset the context of a specified object to what is specified system wide in the file context specifications define by policy, and admin I would suggest one takes a good look at how rpm deals with this, and apply their solution where applicable, because rpm has been doing this for quite a while and so we can imagine that they have learned a lot and adjusted to the optimal way of going things. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685992: /usr/sbin/update-flashplugin-nonfree: Please restore selinux context after installing files
On Thu, 2013-10-10 at 20:05 +0100, Adam D. Barratt wrote: On a related note, dpkg script is not a term generally used within Debian. Are you referring to what we'd call maintainer scripts? (Pre/post removal/installation scripts.) Yes i think that is what this is about. If i understand correctly, files installed/created by the scripts end up mislabeled. But truth be told, i might be wrong. I just see a bunch of mislabeled files when a package gets installed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685992: [Fwd: Re: Bug#685992: /usr/sbin/update-flashplugin-nonfree: Please restore selinux context after installing files]
Seems this this was not sent to the bugzilla Forwarded Message From: Dominick Grift dominick.gr...@gmail.com To: Adam D. Barratt a...@adam-barratt.org.uk Cc: 685...@bugs.debian.org Subject: Re: Bug#685992: /usr/sbin/update-flashplugin-nonfree: Please restore selinux context after installing files Date: Thu, 10 Oct 2013 21:32:05 +0200 On Thu, 2013-10-10 at 20:05 +0100, Adam D. Barratt wrote: On a related note, dpkg script is not a term generally used within Debian. Are you referring to what we'd call maintainer scripts? (Pre/post removal/installation scripts.) Yes i think that is what this is about. If i understand correctly, files installed/created by the scripts end up mislabeled. But truth be told, i might be wrong. I just see a bunch of mislabeled files when a package gets installed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722700: selinux-policy-default: Permission block_suspend in class capability2 not defined in policy.
Yes and you might want to build with UNK_PERMS = allow to avoid similar issues in the future -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
