setuid bit removed from /usr/X11R6/bin/Xorg

[behemoth]

So startx can no longer be used by non-root users.

The best way to start Xorg by non-root users now is:

# rcctl enable xenodm
# rcctl start xenodm

but I prefer to have a command line option as before.

Any solutions?

[jggimi]

You can have xenodm autologin on boot.

The only way to start X from command line is as root, which is not a best practice.

[behemoth]

Ok, many thanks.

[Head_on_a_Stick]

If the setuid bit is manually re-applied then X will run from a console log in as the normal user (but this is also not best practice).

doas chmod u+s $(which Xorg)

Use `chmod u-s` to revert the change.

[jggimi]

Which runs X as root.

[Head_on_a_Stick]

Originally Posted by jggimi

Which runs X as root.

Well, it runs X with elevated privileges, yes, but `top` shows that the process is owned by my user:

62974 empty      2    0   18M   27M sleep/0   poll      0:08  1.76% Xorg

I thought this was what the OP wanted, apologies for the noise if I was mistaken.

[jggimi]

It's a very useful observation, and worthy of discussion.

1. If the setuid and setgid file mode bits are observed by the OS,
2. the executed process is run with the permissions and authority of the user and/or group of the file.
3. The user owner of /usr/X11R6/bin/X is root.

The OS has a mechanism for preventing the use of setgid/setuid divisible by mount point: the mount option nosuid. When set, the OS ignores the setuid and setgid file mode bits of any executable. Unfortunately, the nosuid mount option cannot be set for the filesystem containing /usr/X11R6/bin, as xterm(1) and xlock(1) must use setgid.

X has been shown to have security problems. As an example of this, see patch 001 for 6.4-release. The Project recommended disabling the setuid bit immediately, until the patch could be applied.

The project has improved the security of X further, by disabling the setuid bit permanently for the next release, and requiring the use of xenodm(1) and its privilege separation to initiate the use of X. See the 2016/10/26 entry of the Following -current FAQ.

By re-enabling the setuid bit, you are running X with the permissions and authority of root, and disabling a security feature of the OS.

You might want to reconsider your decision. If for no other reason than this: you might use a browser that runs code provided by a website.

[Head_on_a_Stick]

^ Thanks for the extended explanation, it is very much appreciated.

Originally Posted by jggimi

You might want to reconsider your decision.

I enabled the setuid bit for test purposes only, I usually run xenodm.

Thanks again for the good advice.

[jggimi]

OpenBSD is "Secure by Default." As we can accidentally make our OpenBSD systems "Insecure by Admin," its always a good idea to discuss the security implications of our implementation choices.

[hermano]

Thanks for this discussion. I haven't run into this issue yet, but I guess I will pretty soon!