From: dac.override@gmail.com (Dominick Grift) Date: Mon, 2 Jan 2017 13:54:37 +0100 Subject: [refpolicy] sddm policy help needed In-Reply-To: References: Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 01/02/2017 01:38 PM, cgzones via refpolicy wrote: > Hi list, > I am trying to write a policy module for sddm (Simple Desktop Display Manager). > Currently with the patches over here > https://github.com/cgzones/debian-package-refpolicy/blob/sddm/debian/patches/0041-tryout-sddm.patch > https://github.com/cgzones/debian-package-refpolicy/blob/sddm/debian/patches/0043-add-sddm-module.patch > I am able to login into the correct user contexts and the sddm > processes have proper contexts: > > root at desktopdebian:~# ps -efZ | grep sddm > system_u:system_r:sddm_t:s0 root 4232 1 0 13:09 ? > 00:00:00 /usr/bin/sddm > system_u:system_r:xserver_t:s0 root 4235 4232 1 13:09 tty7 > 00:00:00 /usr/lib/xorg/Xorg -nolisten tcp -auth > /var/run/sddm/{7120015c-2718-4b3a-8b24-7b5c7419b120} -background none > -noreset -displ > ayfd 18 vt7 > system_u:system_r:sddm_helper_t:s0 root 4250 4232 0 13:09 ? > 00:00:00 /usr/lib/x86_64-linux-gnu/sddm/sddm-helper --socket > /tmp/sddm-authca9ac824-d47a-4c2a-92f3-67191cac2336 --id 2 --start > /usr/b > in/sddm-greeter --socket /tmp/sddm-:0-mOnqWf --theme > /usr/share/sddm/themes/breeze --user sddm --greeter > system_u:system_r:sddm_greeter_t:s0 sddm 4255 4250 1 13:09 ? > 00:00:00 /usr/bin/sddm-greeter --socket /tmp/sddm-:0-mOnqWf --theme > /usr/share/sddm/themes/breeze > system_u:system_r:sddm_greeter_t:s0 sddm 4267 1 0 13:09 ? > 00:00:00 dbus-launch --autolaunch b0ac551def43465aa991e56816b44040 > --binary-syntax --close-stderr > system_u:system_r:sddm_dbusd_t:s0 sddm 4268 1 0 13:09 ? > 00:00:00 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 > --session > root:sysadm_r:sysadm_t:s0-s0:c0.c1023 root 4321 4300 0 13:10 tty2 > 00:00:00 grep sddm > > The problem is the sddm-greeter (sddm_greeter_t) process: > This process is responsible for the graphic login window and is > started by sddm-helper (sddm_helper_t). > But it is not created via fork->exec->setuid/setgid (which can be > handled by an SELinux process transition), instead it is spawned via > pam_start (at least I think so). > So the process gets its context via pam authentication and the SELinux > user login mapping gets involved. > That's the reason for this default_contexts entry: > > system_r:sddm_helper_t user_r:user_t staff_r:staff_t sysadm_r:sysadm_t > unconfined_r:unconfined_t system_r:sddm_greeter_t I would probably try transitioning to $1_sddm_t Example: system_r:sddm_helper_t user_r:user_sddm_t Then from there see where this gets me If sddm_helper_t is what sets up the login users context, then you have to transition to a domain that can be used to transition to a login shell domain (hence the prefix in user_sddm_t) That should provide some flexibility. > > sddm-helper is also spawning the user processes, so I only get the > correct sddm-greeter context with the system_r target > (user_r:sddm_greeter_t would collide with the for user login needed > target context user_r:user_t). > To reach the system_r:sddm_greeter_t target, I need to add the SELinux > login mapping for the user sddm by hand: > semamage login -a -s system_u sddm > That's quite cumbersome and leads to the next problem: > The passwd entry for sddm is: sddm:x:122:130:Simple Desktop Display > Manager:/var/lib/sddm:/bin/false > and so genhomedircon creates home dir contexts for sddm and I must not > relabel the directory /var/lib/sddm or any parent directory with the > recursive flag > > root at desktopdebian:~# matchpathcon /var/lib/sddm > /var/lib/sddm system_u:object_r:user_home_dir_t:s0 > > Am I missing something or can these problems be fixed by reworking my > patches or are upstream patches needed (sddm / SELinux userland)? > > Best regards and many thanks in advance, > Christian G?ttsche > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy > -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digital signature Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20170102/9a430c8d/attachment.bin