Another dumb question...

[Stephen Smalley]

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 at epoch.ncsc.mil>
National Security Agency