Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[SOLVED] D-Bus and mount opt nosuid conflict
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
NTU
Apprentice
Apprentice


Joined: 17 Jul 2015
Posts: 163

PostPosted: Tue May 02, 2017 1:23 am    Post subject: [SOLVED] D-Bus and mount opt nosuid conflict Reply with quote

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
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13509

PostPosted: Tue May 02, 2017 4:15 am    Post subject: Reply with quote

Aside from the error message, is anything actually broken? If not, then the simplest thing would be to patch D-Bus to stop complaining.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Tue May 02, 2017 6:43 am    Post subject: Reply with quote

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:

egrep -v '(^#|^$)' /etc/portage/suidctl.conf:
/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:

grep nosuid /etc/fstab:
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
Back to top
View user's profile Send private message
NTU
Apprentice
Apprentice


Joined: 17 Jul 2015
Posts: 163

PostPosted: Tue May 02, 2017 7:31 am    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13509

PostPosted: Wed May 03, 2017 1:40 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
NTU
Apprentice
Apprentice


Joined: 17 Jul 2015
Posts: 163

PostPosted: Wed May 03, 2017 8:14 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13509

PostPosted: Thu May 04, 2017 1:20 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum