[SOLVED] D-Bus and mount opt nosuid conflict

NTU · Apprentice Joined: 17 Jul 2015 Posts: 187

Hey everyone, it's been awhile, how are you all doing?

Quick question for you linux gurus out there, when I emerge dbus (sys-apps/dbus) with nosuid included in my mount opts for / I get error messages after logging into to my LXDE environment via LightDM login manager.

I'd post this in the desktop board but I think this is more of a security concern than a desktop environment issue, but feel free to move this there if you wish!

Is there any possible way to use a login manager (PAM enabled) which essentially means having to use D-Bus, without affecting my fstab and I can leave nosuid enabled for /? If not, is there a way to have /usr/libexec without nosuid as a mount option, without having to create a new partition on my drive, specifically just for /usr/libexec?

D-bus is the only application I'm aware of that requires this kind of thing and I think it's a bit silly to have to change fstab to revolve around D-Bus and it's horrible code design.

Thanks!

Hu · Administrator Joined: 06 Mar 2007 Posts: 23470

Aside from the error message, is anything actually broken? If not, then the simplest thing would be to patch D-Bus to stop complaining.

khayyam · Posted: Tue May 02, 2017 6:43 am Post subject:

NTU ...

In general I would say you probably don't want to completely do away with suid, you may need it for things like /sbin/su to function. That said you can use FEATURES="suidctl" the control what suid are installed, eg:

NTU · Apprentice Joined: 17 Jul 2015 Posts: 187

Hu · Administrator Joined: 06 Mar 2007 Posts: 23470

If preventing elevation is your main concern, another option would be to use setpriv --no-new-privs, which irrevocably sets a flag that prevents the executed process from gaining privileges by way of suid. This is much more fine-grained, but also much more extensive, since it is done on a per-process basis and applies to anything that process might execute. The flag is inherited across fork and can never be cleared, so if your login session is started with no-new-privs, all your shells, your mail client, your browser, etc. will inherit it and be unable to set uid.

NTU · Apprentice Joined: 17 Jul 2015 Posts: 187

Hu · Administrator Joined: 06 Mar 2007 Posts: 23470

I do not remember where I learned of this. Beware using it too broadly, as any shell run under --no-new-privs runs all its children without setuid, including /bin/su when you try to elevate to root. If you want a root shell, you must log in directly as root from a getty or execute /bin/su from a process that is not under --no-new-privs. Likewise, ping may be unusable under this restriction. With those disclaimers, the easiest way to use it would be to insert /usr/bin/setpriv --no-new-privs -- before executing any process that you are willing to confine. If you have no need of elevation at all in your X session, you could put it in your .xinitrc.

You are correct that normal user processes should not elevate. Internet-facing applications ought to be confined by this unless there is a very compelling reason otherwise. The only reason not to set this everywhere is if you are the type of person who opens an xterm, runs /bin/su - in it, and then performs system administration from the resulting root shell.