Hi,
In debian, sudo is currently storing the timestamp use to check the last
time a user has given a password in /var/lib/sudo.
Due to bug #786555[0] the sudo maintainer is thinking of moving the
files to /var/run/sudo/, but on debian /var/run is a tmpfs and the
directory needs to be recreated at every boot. sudo itself can create
that itself, but the problem is that the directory is not properly label
if the user invoking sudo is unconfined:
$ sesearch -AT |grep pam_var_run_t |grep sudo
allow auditadm_sudo_t pam_var_run_t:dir { getattr reparent create lock add_name read remove_name ioctl search unlink link rmdir open write rename setattr };
allow auditadm_sudo_t pam_var_run_t:file { getattr create lock read ioctl append unlink link open write rename setattr };
allow secadm_sudo_t pam_var_run_t:dir { getattr reparent create lock add_name read remove_name ioctl search unlink link rmdir open write rename setattr };
allow secadm_sudo_t pam_var_run_t:file { getattr create lock read ioctl append unlink link open write rename setattr };
allow staff_sudo_t pam_var_run_t:dir { getattr reparent create lock add_name read remove_name ioctl search unlink link rmdir open write rename setattr };
allow staff_sudo_t pam_var_run_t:file { getattr create lock read ioctl append unlink link open write rename setattr };
allow sysadm_sudo_t pam_var_run_t:dir { getattr reparent create lock add_name read remove_name ioctl search unlink link rmdir open write rename setattr };
allow sysadm_sudo_t pam_var_run_t:file { getattr create lock read ioctl append unlink link open write rename setattr };
allow user_sudo_t pam_var_run_t:dir { getattr reparent create lock add_name read remove_name ioctl search unlink link rmdir open write rename setattr };
allow user_sudo_t pam_var_run_t:file { getattr create lock read ioctl append unlink link open write rename setattr };
type_transition auditadm_sudo_t var_run_t:dir pam_var_run_t "sudo";
type_transition secadm_sudo_t var_run_t:dir pam_var_run_t "sudo";
type_transition staff_sudo_t var_run_t:dir pam_var_run_t "sudo";
type_transition sysadm_sudo_t var_run_t:dir pam_var_run_t "sudo";
type_transition user_sudo_t var_run_t:dir pam_var_run_t "sudo";
One of the solution might be to either ask sudo to properly label the
directory using setfscreatecon() or to create the file using a tempfile
file or an initscript. But shouldn't rules be added in the policy to
transition the directory to be properly label?
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786555
I asked the fedora maintainer to add a tmpfiles snippet:
# cat /etc/tmpfiles.d/sudo.conf
# Create an empty sudo time stamp directory on OSes using systemd.
# Sudo will create the directory itself but this can cause problems
# on systems that have SELinux enabled since the directories will be
# created with the user's security context.
d /run/sudo 0711 root root
D /run/sudo/ts 0700 root root
Any other solution wouldnt work well with DSSP2's RBACsep security model
On Mon, Jul 17, 2017 at 11:33:12AM +0200, Laurent Bigonville via refpolicy wrote:
> Hi,
>
> In debian, sudo is currently storing the timestamp use to check the last
> time a user has given a password in /var/lib/sudo.
>
> Due to bug #786555[0] the sudo maintainer is thinking of moving the
> files to /var/run/sudo/, but on debian /var/run is a tmpfs and the
> directory needs to be recreated at every boot. sudo itself can create
> that itself, but the problem is that the directory is not properly label
> if the user invoking sudo is unconfined:
>
> $ sesearch -AT |grep pam_var_run_t |grep sudo
> allow auditadm_sudo_t pam_var_run_t:dir { getattr reparent create lock add_name read remove_name ioctl search unlink link rmdir open write rename setattr };
> allow auditadm_sudo_t pam_var_run_t:file { getattr create lock read ioctl append unlink link open write rename setattr };
> allow secadm_sudo_t pam_var_run_t:dir { getattr reparent create lock add_name read remove_name ioctl search unlink link rmdir open write rename setattr };
> allow secadm_sudo_t pam_var_run_t:file { getattr create lock read ioctl append unlink link open write rename setattr };
> allow staff_sudo_t pam_var_run_t:dir { getattr reparent create lock add_name read remove_name ioctl search unlink link rmdir open write rename setattr };
> allow staff_sudo_t pam_var_run_t:file { getattr create lock read ioctl append unlink link open write rename setattr };
> allow sysadm_sudo_t pam_var_run_t:dir { getattr reparent create lock add_name read remove_name ioctl search unlink link rmdir open write rename setattr };
> allow sysadm_sudo_t pam_var_run_t:file { getattr create lock read ioctl append unlink link open write rename setattr };
> allow user_sudo_t pam_var_run_t:dir { getattr reparent create lock add_name read remove_name ioctl search unlink link rmdir open write rename setattr };
> allow user_sudo_t pam_var_run_t:file { getattr create lock read ioctl append unlink link open write rename setattr };
> type_transition auditadm_sudo_t var_run_t:dir pam_var_run_t "sudo";
> type_transition secadm_sudo_t var_run_t:dir pam_var_run_t "sudo";
> type_transition staff_sudo_t var_run_t:dir pam_var_run_t "sudo";
> type_transition sysadm_sudo_t var_run_t:dir pam_var_run_t "sudo";
> type_transition user_sudo_t var_run_t:dir pam_var_run_t "sudo";
>
> One of the solution might be to either ask sudo to properly label the
> directory using setfscreatecon() or to create the file using a tempfile
> file or an initscript. But shouldn't rules be added in the policy to
> transition the directory to be properly label?
>
> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786555
>
> _______________________________________________
> 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: not available
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20170717/3618db9b/attachment.bin
On Mon, Jul 17, 2017 at 11:56:25AM +0200, Dominick Grift wrote:
> I asked the fedora maintainer to add a tmpfiles snippet:
>
> # cat /etc/tmpfiles.d/sudo.conf
> # Create an empty sudo time stamp directory on OSes using systemd.
> # Sudo will create the directory itself but this can cause problems
> # on systems that have SELinux enabled since the directories will be
> # created with the user's security context.
> d /run/sudo 0711 root root
> D /run/sudo/ts 0700 root root
>
> Any other solution wouldnt work well with DSSP2's RBACsep security model
... and refpolicy's IBACsep model for that matter
>
> On Mon, Jul 17, 2017 at 11:33:12AM +0200, Laurent Bigonville via refpolicy wrote:
> > Hi,
> >
> > In debian, sudo is currently storing the timestamp use to check the last
> > time a user has given a password in /var/lib/sudo.
> >
> > Due to bug #786555[0] the sudo maintainer is thinking of moving the
> > files to /var/run/sudo/, but on debian /var/run is a tmpfs and the
> > directory needs to be recreated at every boot. sudo itself can create
> > that itself, but the problem is that the directory is not properly label
> > if the user invoking sudo is unconfined:
> >
> > $ sesearch -AT |grep pam_var_run_t |grep sudo
> > allow auditadm_sudo_t pam_var_run_t:dir { getattr reparent create lock add_name read remove_name ioctl search unlink link rmdir open write rename setattr };
> > allow auditadm_sudo_t pam_var_run_t:file { getattr create lock read ioctl append unlink link open write rename setattr };
> > allow secadm_sudo_t pam_var_run_t:dir { getattr reparent create lock add_name read remove_name ioctl search unlink link rmdir open write rename setattr };
> > allow secadm_sudo_t pam_var_run_t:file { getattr create lock read ioctl append unlink link open write rename setattr };
> > allow staff_sudo_t pam_var_run_t:dir { getattr reparent create lock add_name read remove_name ioctl search unlink link rmdir open write rename setattr };
> > allow staff_sudo_t pam_var_run_t:file { getattr create lock read ioctl append unlink link open write rename setattr };
> > allow sysadm_sudo_t pam_var_run_t:dir { getattr reparent create lock add_name read remove_name ioctl search unlink link rmdir open write rename setattr };
> > allow sysadm_sudo_t pam_var_run_t:file { getattr create lock read ioctl append unlink link open write rename setattr };
> > allow user_sudo_t pam_var_run_t:dir { getattr reparent create lock add_name read remove_name ioctl search unlink link rmdir open write rename setattr };
> > allow user_sudo_t pam_var_run_t:file { getattr create lock read ioctl append unlink link open write rename setattr };
> > type_transition auditadm_sudo_t var_run_t:dir pam_var_run_t "sudo";
> > type_transition secadm_sudo_t var_run_t:dir pam_var_run_t "sudo";
> > type_transition staff_sudo_t var_run_t:dir pam_var_run_t "sudo";
> > type_transition sysadm_sudo_t var_run_t:dir pam_var_run_t "sudo";
> > type_transition user_sudo_t var_run_t:dir pam_var_run_t "sudo";
> >
> > One of the solution might be to either ask sudo to properly label the
> > directory using setfscreatecon() or to create the file using a tempfile
> > file or an initscript. But shouldn't rules be added in the policy to
> > transition the directory to be properly label?
> >
> > [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786555
> >
> > _______________________________________________
> > 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
--
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: not available
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20170717/61bf5f0b/attachment.bin