FS#26682 - Strip capabilities from /usr/bin/Xorg

Attached to Project: Arch Linux
Opened by Leonid Isaev (lisaev) - Saturday, 29 October 2011, 20:32 GMT
Last edited by Jan de Groot (JGC) - Monday, 07 November 2011, 13:15 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Fedora has already gone the suid-less way since F15 [1] and there are some notes on our wiki too [2,3]. The reason why I don't mention ping and the like is because these are relatively low-profile and well-written apps, while X runs on nearly 100% of arch installs.

Currently /usr/bin/Xorg is 4755 root:root (suid), with full capabilities. It makes sense to lower its capabilities using fs capabilities [4]. The set of capabilities which works OK for me (shamelessly taken from fedora xorg-xserver spec file) is:
$ filecap /usr/bin/Xorg
file capabilities
/usr/bin/Xorg dac_override, sys_rawio, sys_admin
(No idea who put cap_chown in the wiki). Root-less X has been working OK for me for some time already:
$ ps -e u | grep X | grep tty3
lisaev 1389 1.4 0.6 131316 27224 tty3 Ss+ 14:30 0:35 /usr/bin/X :0 -nolisten tcp -logverbose 7 -verbose 7 -auth /tmp/serverauth.8B4S9TugUo

Of course a user has to have the filesystem which actually supports file capabilites. I tested successfully on i686 jfs (kvm) and x64 ext4 (real).

Lowering capabilities does not actually require to remove suid bit, as the kernel will choose the lowest set of effective capabilities:
$ cat /var/log/kernel.log| grep "/usr/bin/X"
Oct 29 14:19:36 bluemoon kernel: [11051.613397] warning: `/usr/bin/X' has both setuid-root and effective capabilities. Therefore not raising all capabilities.
Without the suid bit there appears a (harmless) warning in /var/log/Xorg.log:
$ grep "(WW)" /var/log/Xorg.0.log| grep -i "user id"
[ 128.970] (WW) LoadKernelModule: Setting of real/effective user Id to 0/0 failed[ 128.971] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
which probably indicates that X has a hardcoded UID check.

Thanks.

[1] http://fedoraproject.org/wiki/Features/RemoveSETUID
[2] https://wiki.archlinux.org/index.php/Using_File_Capabilities_Instead_Of_Setuid#xorg-xserver
[3] http://archlinux.me/brain0/2010/01/05/using-posix-capabilities-in-linux-part-two/
[4] man 7 capabilities
This task depends upon

Closed by  Jan de Groot (JGC)
Monday, 07 November 2011, 13:15 GMT
Reason for closing:  Won't implement
Additional comments about closing:  From the fedora specfile (also in git master):
%if 1
%define Xorgperms %attr(4711, root, root)
%else
# disable until module loading is audited
%define Xorgperms %attr(0711,root,root) %caps(cap_sys_admin,cap_sys_rawio,cap_da c_override=pe)
%endif
Comment by Dave Reisner (falconindy) - Saturday, 29 October 2011, 21:40 GMT
A move such as this would preclude users of the nvidia and catalyst drivers. KMS is a _must_ for this to work.

https://wiki.ubuntu.com/X/Rootless
Comment by Leonid Isaev (lisaev) - Saturday, 29 October 2011, 22:23 GMT
I think we are talking about different things here.

With KMS one, in principle, can have an X which needs no root privs as well as no elevated caps, since all the work is done by the kernel. So you are right in that catalyst uses are out in this scenario (not sure about nvidia though). However, the work along these lines seems to have stalled (latest I could find were some ML posts by intel people around early 2010).

X w/o full capabilities still has more capabilities than your average firefox process, but runs as an unpriviledged user. As I said before, I ran it in a VM for a while, which uses vmware drivers and needs no KMS (in fact I checked with "nomodeset" in the kernel command line).
Comment by Dave Reisner (falconindy) - Saturday, 29 October 2011, 22:33 GMT
No, this is the same line of thought, but I'm taking it a step further.

I don't see much of a difference between giving a process CAP_DAC_OVERRIDE/CAP_SYS_ADMIN and running as root. What exactly is gained by this? Can you provide evidence of other distros doing this odd halfway business instead of aiming for the moon?
Comment by Leonid Isaev (lisaev) - Saturday, 29 October 2011, 23:24 GMT
> No, this is the same line of thought, but I'm taking it a step further.
I agree that it's still a hack and doesn't solve the problem completely... better than nothing though while waiting for upstream.

> What exactly is gained by this?
Honestly, I am not aware of any attack which was avoided by doing this.

> Can you provide evidence of other distros doing this odd halfway business instead of aiming for the moon?
Fedora [1,5,6], as I already mentioned, not sure about others.

[5] https://bugzilla.redhat.com/show_bug.cgi?id=646440.
[6] attachment
   xorg-x11-server.spec (68.7 KiB)
Comment by Jason William Walton (jasonww) - Saturday, 29 October 2011, 23:24 GMT
Pretty much pointless given that X retains all the strong capabilities when broad support is required.

Do all filesystems support capabilites? What when file capabilities aren't compiled into the kernel?

Also capabilities are unspported in tmpfs on Kernels older than 2.6.39, breaking at least the package build and other uncommon usage scenarios.

This is garbage. Imho - If you want this, do it yourself.
Comment by Leonid Isaev (lisaev) - Saturday, 29 October 2011, 23:26 GMT
> Do all filesystems support capabilites? What when file capabilities aren't compiled into the kernel?
Have you even read past the topic?
Comment by Jason William Walton (jasonww) - Saturday, 29 October 2011, 23:28 GMT
setxattr("/usr/bin/Xorg", "security.capability", "\x01\x00\x00\x02\x03\x00"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00", 20, 0) = -1 EOPNOTSUPP (Operation not supported)

Hello.

Okay, the kernel will try to not be stupid. Got that now.

Loading...