Bug 1285991

Colin

I'm the developer of dnfdaemon/yumex-dnf and hope you can guide me the in the right direction for solving this issue.

The upstream for the daemon is located here.
https://github.com/timlau/dnf-daemon

See https://git.gnome.org/browse/gobject-introspection/commit/?id=98bb6c91b710a95efe4cfeb303daeec3381b9c98

It's possible we regressed here because dbus uses a setuid helper to launch daemons.  I thought though AT_SECURE would be cleared when the helper itself execve's the target.  

Regardless, you can work around this by telling systemd about the bus name for your app.  See e.g. the polkit package for this.  It would likely avoid the issue as systemd doesn't use a setuid binary.  Using systemd for activation also brings other advantages too.

The above said, this is a regression, and there may be no choice other than to revert it.

Thanks a lot, I will make dnfdaemon use systemd for activation

We're also experiencing this issue with firewalld on Fedora 24:

Dec 09 16:13:33 pungent.sgallagh.rht systemd[1]: Starting firewalld - dynamic firewall daemon...
Dec 09 16:13:33 pungent.sgallagh.rht firewalld[3511]: error: libgirepository.so (gobject-introspection) is not audited for use in setuid applications
Dec 09 16:13:33 pungent.sgallagh.rht firewalld[3511]: See https://bugzilla.gnome.org/show_bug.cgi?id=755472
Dec 09 16:13:33 pungent.sgallagh.rht systemd[1]: firewalld.service: Main process exited, code=exited, status=1/FAILURE
Dec 09 16:13:33 pungent.sgallagh.rht systemd[1]: Failed to start firewalld - dynamic firewall daemon.
Dec 09 16:13:33 pungent.sgallagh.rht systemd[1]: firewalld.service: Unit entered failed state.
Dec 09 16:13:33 pungent.sgallagh.rht audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=firewalld comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Dec 09 16:13:33 pungent.sgallagh.rht systemd[1]: firewalld.service: Failed with result 'exit-code'.
Dec 09 16:13:33 pungent.sgallagh.rht polkitd[828]: Unregistered Authentication Agent for unix-process:3505:126580 (system bus name :1.33, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)

http://koji.fedoraproject.org/koji/taskinfo?taskID=12129720

That said, comment #2 applies to firewalld to - better to link it up with systemd.

Do we know what causes the kernel to set the AT_SECURE flag?

execve should definitely reset AT_SECURE.  However, I see this:

-rwxr-xr-x. 1 root root system_u:object_r:firewalld_exec_t:s0 6255 Jul 22 23:57 /usr/sbin/firewalld

So firewalld runs in AT_SECURE mode.  Upstream has indicated that girepository does not support this kind of usage because it has not been designed with this situation in mind.  What do we do now?  Harden girepository so that it is safe to use in this context?  Move daemons away from girepository?

Oh duh, it's a domain transition, not classic setuid that sets AT_SECURE *again* because we're going setuid -> domain.

We could introduce a "classic" getuid() != geteuid() check upstream, which would likely work and close off the biggest threats from people blindly doing chown root /usr/bin/myapp && chmod u+s /usr/bin/myapp, with the same rationale GTK+ has.

I think in reality there's not much threat for SELinux because most confined domains shouldn't be able to transition to other confined domains.  For example, I think sssd_t can't transition to firewalld_t, it's just going to "execute_no_trans".

(And this implies that moving to systemd activation doesn't help, because systemd will still do a transition)

I thought though someone (possibly Andy Lutomirski) did some work upstream on "fully bounded transitions" or so where if the source domain is fully privileged (like unconfined_t or systemd) we still support transitions.  Maybe that was for PR_SET_NO_NEW_PRIVS or something.

(A minute passes while /me searches with git log --grep)

Ah yes, https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7b0d0b40cd78cadb525df760ee4cac151533c2b5

However, selinux_bprm_secureexec() ignores this, and just does:

	int atsecure = 0;

	if (osid != sid) {
		atsecure = avc_has_perm(osid, sid,
					SECCLASS_PROCESS,
					PROCESS__NOATSECURE, NULL);
	}

	return !!atsecure;

Which means that even for these bounded transitions we still set AT_SECURE, which doesn't seem necessary.

/me lights a few black candles and summons Paul to the CC list

TL;DR - we would like to have userspace libraries check for AT_SECURE if these libraries use e.g. getenv() and such in a way that could be exploited[1], and we don't want to support their use in setuid applications.

But while setuid applications are relatively rare, SELinux domain transitions are not, and having AT_SECURE set for even "fully bounded" transitions means we can't really add userspace checks like the above.

[1] Example: http://cgit.freedesktop.org/dbus/dbus/commit/?id=a52319bc294d05445fd8aa8f4a7f759c34558b5d

The NNP/NOSUID bounded domain transition work and the AT_SECURE stuff in selinux_bprm_secureexec() are different things.  The NNP/NOSUID/bounded_transition code in check_nnp_nosuid() is concerned about when to allow a domain transition whereas the AT_SECURE code in selinux_bprm_secureexec() is concerned about setting the AT_SECURE flag when a domain transition has taken place and the domain has not been granted the SELinux process:noatsecure permission.

I'm not too familiar with the processes we are talking about in this BZ to understand if granting their respective domains the process:noatsecure permission is the correct thing to do, but doing so would result in SELinux not setting the AT_SECURE flag when the domain transition takes place.

I'm also adding mgrepl to the CC line as he is our policy guru and might have some thoughts/suggestions.

I am thinking that `process:noatsecure` is basically a *manual* way to say "we trust domain A to execute B without trying to use it as a privilege escalation vector".  Or perhaps in doing so we're kind of asserting that B's executable doesn't have any trivial ways to use environment variables to execute arbitrary code?

But a fully bounded transition (as systemd and the dbus helper should be) is an automatic way to do that.

To flip it around, are there any cases where we are using `noatsecure` now that would *not* be covered if we just replaced it with bounded_transition?

That said I'm not going to claim I've fully thought through all of the implications, and maybe it's not worth doing so - the effort might be better spent on removing setuid binaries and consigning all issues like this to the dustbin of history.


Update: I just glanced at policy and it looks like there may be cases, e.g. user roles can transition to $user_java_t just for execmem...so we'd need to keep `noatsecure` as a manual method too.

There's a lot of useful discussion here, but the bug here is closed.

Florian, can you add this bug as a reference to whatever spreadsheet or system you're using for "hardening" tasks?