On Sun, 2004-04-04 at 08:25, Jonathan Rawle wrote: > But reading the existing documentation, I thought the idea of a SELinux > identity being separate from the Unix user ID was that it couldn't change, > so that it was possible to track people's activity, hold administrators to > account, and to ensure users couldn't obtain escalating privileges. 1) Tracking people's activity and holding administrators to account (i.e. user accountability) is principally a job for an audit framework. As RedHat has introduced such an audit framework via a separate patch, it should be possible to preserve logging of the original login user identity using that audit framework rather than SELinux. Also, the existing SELinux auditing of permission checks could be configured to audit all transitions to and from the su domains, such that the SELinux user identity transitions would be logged as they occur, e.g. adding something like 'auditallow $1_t $1_su_t:process transition; auditallow $1_su_t userdomain:process transition;' to policy/macros/program/su_macros.te (caveat: untested). 2) Privilege escalation can still be bounded based on domain transitions. If you disable the unlimitedUsers and user_canbe_sysadm tunables that RedHat introduced, then user_t cannot use su and cannot transition to sysadm_t; only a staff_t user can use su to transition to sysadm_t. > If RedHat have made the SELinux identity change with su, then it is > identical to the Unix ID. Not identical, e.g. a setuid program still doesn't change the SELinux user identity, and a call to set*uid() by a program doesn't change the SELinux user identity. Only programs that have been specifically modified (typically via pam_selinux) will perform transitions in the SELinux user identity. -- Stephen Smalley <sds@xxxxxxxxxxxxxx> National Security Agency
