# [SOLVED] D-Bus and mount opt nosuid conflict

## NTU

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!Last edited by NTU on Tue May 02, 2017 7:32 am; edited 1 time in total

----------

## Hu

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

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:

```
/bin/su

/usr/sbin/postdrop

/usr/sbin/postqueue
```

In the case of dbus you may be able to use linux capabilities to provide it with whatever access it needs (and so avoid the use of suid). I'm not sure what those capabilities are but it's probably cap_setgid and/or cap_setuid (probably a google search will provide a more definitive answer).

Also, I assume when you say "/" you mean one partition, it might be a better approach to limit nosuid to specific mounts:

```
LABEL=var   /var        ext4   defaults,relatime,nosuid,nodev      0  2

LABEL=home  /home       ext4   defaults,relatime,nosuid,nodev      0  2

tmpfs       /tmp        tmpfs  rw,relatime,nosuid,nodev  0  0
```

... that, of course, is no help if you happen to don't happen to have a seperate /home, /var, or what-have-you, but for completeness sake there you have it.

HTH & best ... khay

----------

## NTU

 *Hu wrote:*   

> the simplest thing would be to patch D-Bus to stop complaining.

 

That's actually not a bad idea until I'm able to fix it properly with linux caps in khayyam's suggestion. Thanks! Having root mounted with nosuid helps prevent against gaining root privileges so I'm going to leave the nosuid option intact until the more plausible solution is figured out.

Marking as SOLVED, thank you both!

----------

## Hu

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

 *Hu wrote:*   

> 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.

 

Wow! How did you come across this? Do you have any examples / tips on implementing this system-wide?

I see no reason why permissions should ever change on the fly for processes. Mail clients, web browser etc should be able to access, R/W, to/from whatever dirs and files the user and it's child processes can, and they certainly should never escalate to anything beyond that, unless you can think of a good reason?

----------

## Hu

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.

----------

