Loginuid, should be allowed to change or not (mutable or not)?

Question

I am trying to configure the linux kernel. I was confused by Make audit loginuid immutable (AUDIT_LOGINUID_IMMUTABLE) [N/y/?].

The help says:

+config AUDIT_LOGINUID_IMMUTABLE
+ bool "Make audit loginuid immutable"
+ depends on AUDIT
+ help
+ The config option toggles if a task setting it's loginuid requires
+ CAP_SYS_AUDITCONTROL or if that task should require no special permissions
+ but should instead only allow setting its loginuid if it was never
+ previously set. On systems which use systemd or a similar central
+ process to restart login services this should be set to true. On older
+ systems in which an admin would typically have to directly stop and
+ start processes this should be set to false. Setting this to true allows
+ one to drop potentially dangerous capabilites from the login tasks,
+ but may not be backwards compatible with older init systems.

Is loginuid the same as euid which can be changed so that, that particular process gains more privilege and permissions?

If not, then can you explain it in simpler terms? Is it like, starting the process with more privileges like sudo [process] or giving a process more permissions during execution or only people who can execute su (system admins or root) can make use of this setting?

Answer 1

The accepted answer is inaccurate. My answer may also be questionably accurate or hard to follow, but it seems worth sharing. :) This kernel option determines if anyone can just "echo 0 > /proc/self/loginuid" when loginuid is unset and then it remains unchanged, or if modifications to that value require a specific capability regardless of current value. When this is true (which typically means you're root), loginuid can only be modified if it's unset. The reason the accepted answer is inaccurate is that sudo and su are typically both suid root. They are suid root in order to allow the binary to switch to a different effective UID. In most Linux systems, the root user has all capabilities by default. Therefore, those programs also have the capability of switching the loginuid attribute if this is false. If this is true and the system is properly configured, loginuid should have been set in the login shell by ssh/login/whatever, and nothing can change the value.

The loginuid attribute is unset at system startup / within init. It is typically first set by the pam_loginuid module on "entry point" services. So, you set up ssh and login to set a value, as those are things which would allow someone to "log in" - hence loginuid. You wouldn't include the module in the sudo pam stack, for example, because that's not a new login; that's switching UIDs after logging in. The purpose of loginuid is to track a user from login time. You can use the audit daemon to record processes run by a specific user, even after they've switched accounts with su or sudo. The logname utility uses this attribute on newer systems to identify the "logged in user" independently of the effective or real uid values (older systems use the controlling terminal to look up a login event from utmp).

Processes inherit the loginuid attribute from their parent process, BTW.

So, this parameter controls whether the loginuid attribute can be modified. It mentions systemd because of how init works. The kernel starts init, and init has no loginuid. Then init starts services, and those have unset loginuids. With regular System V init, an admin might log in and, say, run "/etc/init.d/someservice restart". The admin's loginuid attribute is set when they ssh in, and that carries forward to switching to root. Then they run the init script, which inherits their loginuid. If the "loginuid immutable" value is set, the init script or admin can't make the system call which either clears or resets the lognuid attribute before starting the daemon, and now the daemon is running with the admin's loginuid, screwing up audit logs, etc. If the value is modifiable, then there is a system call (audit_setloginuid()) which can be made by a process with appropriate capabilities (perhaps /sbin/service, for example) to clear or set a reasonable value for loginuid on the given daemon.

The way systemd (and upstart, and perhaps some other init systems) work, the admin doesn't directly run the init scripts. Instead, the admin sends a command to the init process, and the init process then does the restart (or whatever) action on its own. Since init has an unset loginuid, the spawned init script inherits that value (unset), and then the init script can set its own loginuid even though it may have been run as a non-root user. It's arguably more secure, since nothing needs special capabilities; everything can be done as a regular user.

So, if you have a decoupled init system, there is generally no legitimate reason for anything non-root to be changing the loginuid attribute once it's initially set, and thus it can be set essentially immutable.

To answer the question about "what does this give you," well, not much. There are probably programs out there which grant access based on the loginuid rather than the uid or euid, but those are few and far between. In general, access is controlled based on SELinux contexts, EUID, UID, or process capabilities. Changing your loginuid to 0 shouldn't get you anything - and should probably trigger a monitoring system designed to catch remote root logins. :) Some sites use auditd to track process execution / system calls, and those sites may well need loginuid to be accurate in order to have working system audit rules. But if you're asking this question about a kernel you're compiling, you are not operating one of those sites. :)

Answer 2

The documentation for the pam_loginuid PAM module gives a pretty good hint:

The pam_loginuid module sets the loginuid process attribute for the process that was authenticated. This is necessary for applications to be correctly audited. This PAM module should only be used for entry point applications like: login, sshd, gdm, vsftpd, crond and atd. There are probably other entry point applications besides these. You should not use it for applications like sudo or su as that defeats the purpose by changing the loginuid to the account they just switched to.

So as the last paragraph mentions, the loginuid attribute could be changed when running sudo or su, and the AUDIT_LOGINUID_IMMUTABLE kernel option prevents this.

Also, here's the relevant source code (second if) from Linux 3.15:

static int audit_set_loginuid_perm(kuid_t loginuid)
{
    /* if we are unset, we don't need privs */
    if (!audit_loginuid_set(current))
        return 0;
    /* if AUDIT_FEATURE_LOGINUID_IMMUTABLE means never ever allow a change*/
    if (is_audit_feature_set(AUDIT_FEATURE_LOGINUID_IMMUTABLE))
        return -EPERM;
    /* it is set, you need permission */
    if (!capable(CAP_AUDIT_CONTROL))
        return -EPERM;
    /* reject if this is not an unset and we don't allow that */
    if (is_audit_feature_set(AUDIT_FEATURE_ONLY_UNSET_LOGINUID) && uid_valid(loginuid))
        return -EPERM;
    return 0;
}

^{(Sacrilege note: tabs have been replaced with 4 spaces to make the code fit better here.)}