User avatar
thagrol
Posts: 5215
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

startx at boot single client and unprivileged user

Sun Jun 13, 2021 4:32 pm

Pi model: any
OS: RPiOS full booting to command line without auto loginn
Aim: a reliable and resonably secure way to run startx /path/to/program at boot as an unprivileged user (i.e. not as root).

Whether from cron, rc.local or systemd trying to run startx /path/to/program as a user other than root always fails with a permission denied error on the tty. I have a few workarounds but none are ideal:
  1. Run as root and hang the consequences.
  2. Run as root and have the program drop its privileges. Not possible if you don't have the program source and the necessary knowledge to modify it. Potential complications with thing like ~, $HOME, $PATH, etc
  3. Autologin to a non-root user's command line then run it from their .bashrc. Obivous problem there is .bashrc runs at every login whether local or remote, GUI or command line. Anyone with physial access running has access to a logged in commandline just by connecting a keyboard. With passwordless sudo in the default OS configuration.
  4. Autologin to a non-root user's desktop and use autostart. Anyone with physial access running has access to a logged in desktop just by connecting a keyboard. With passwordless sudo in the default OS configuration.
  5. Install the xserver-xorg-legacy package and configure it so anybody can start the X server. The downside here is that anybody can start the X server on the console as long as it isn't running and they have login credential to the box.
I'm currently leaning towards the last method, possibly combined with reconfiguring xserver-xorg-legacy to restrict access once the desired program has started.

But I'd like to know if there is a more secure and more reliable method.

Before anyone suggests a systemd service wantedby and after graphical.target, that won't help. You'll hit a different set of X security issues and potentially still have a logged in desktop running.
I'm a volunteer. Take me for granted or abuse my support and I will walk away

All advice given is based on my experience. it worked for me, it may not work for you.
Need help? https://github.com/thagrol/Guides

User avatar
kerry_s
Posts: 2153
Joined: Thu Jan 30, 2020 7:14 pm

Re: startx at boot single client and unprivileged user

Sun Jun 13, 2021 4:44 pm

Code: Select all

sudo systemctl edit getty@tty1
put in first open line:

Code: Select all

[Service]
ExecStart=
ExecStart=-/usr/bin/agetty --autologin pi --noclear %I $TERM
to start, put in .profile/.bash_profile? what ever raspberry uses.

Code: Select all

if [ -z $DISPLAY ] && [ "$(tty)" = "/dev/tty1" ]; then
  exec starx
fi

User avatar
thagrol
Posts: 5215
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: startx at boot single client and unprivileged user

Sun Jun 13, 2021 5:50 pm

kerry_s wrote:
Sun Jun 13, 2021 4:44 pm

Code: Select all

sudo systemctl edit getty@tty1
put in first open line:

Code: Select all

[Service]
ExecStart=
ExecStart=-/usr/bin/agetty --autologin pi --noclear %I $TERM
to start, put in .profile/.bash_profile? what ever raspberry uses.

Code: Select all

if [ -z $DISPLAY ] && [ "$(tty)" = "/dev/tty1" ]; then
  exec starx
fi
Thanks, but isn't that a variation on
thagrol wrote:
Sun Jun 13, 2021 4:32 pm
Autologin to a non-root user's command line then run it from their .bashrc.
Yes, that's example code of how to only launch startx when running on the console via .bashrc but there is still the issue of an active login. Though at least with exec there won't be a shell to fall back to when/if the X server exits.
I'm a volunteer. Take me for granted or abuse my support and I will walk away

All advice given is based on my experience. it worked for me, it may not work for you.
Need help? https://github.com/thagrol/Guides

User avatar
RamaSpaceShip
Posts: 164
Joined: Sun Apr 26, 2020 12:19 pm

Re: startx at boot single client and unprivileged user

Sun Jun 13, 2021 7:13 pm

I have a similar use case:
- RPiOS Lite + necessary X packages
- method 5
- no mouse, no keyboard
- touch screen, when there is one, is invalidated for the X server, and its events are handled by our application directly
- the Pi is in a box secured by a key.

Of course, we manage the code, so it's a lot easier to handle the side things.

As you wrote, the login remains possible and thus should be restricted to only trusted people.

Whatever the solution you choose, if someone can login, there is a security risk. So login is something that needs to be secured.

User avatar
thagrol
Posts: 5215
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: startx at boot single client and unprivileged user

Sun Jun 13, 2021 8:18 pm

RamaSpaceShip wrote:
Sun Jun 13, 2021 7:13 pm
Whatever the solution you choose, if someone can login, there is a security risk. So login is something that needs to be secured.
Indeed. But that applies to pretty much any use of linux.
I'm a volunteer. Take me for granted or abuse my support and I will walk away

All advice given is based on my experience. it worked for me, it may not work for you.
Need help? https://github.com/thagrol/Guides

User avatar
kerry_s
Posts: 2153
Joined: Thu Jan 30, 2020 7:14 pm

Re: startx at boot single client and unprivileged user

Sun Jun 13, 2021 8:50 pm

sorry, i was heading to bed & didn't read it good.

swampdog
Posts: 718
Joined: Fri Dec 04, 2015 11:22 am

Re: startx at boot single client and unprivileged user

Sun Jun 13, 2021 9:56 pm

I'm not certain as to your precise requirements but I've had a play. To summarise (and expect this to fail whenever) - if you lock out the GUI user and change their login shell the GUI still fires up.

Code: Select all

# passwd -l pi
# usermod -s /usr/sbin/nologin pi
..no terminal. More importantly if I'm guessing right, should you ctrl-alt out of the GUI, "pi" can't login and especially ctrl-alt-f1 sees the autologin has failed. ie: set raspi-config such that it tries to autologin the GUI user.

I tried other things including a setuid/setgid C hack but there's just too much faff X has to do. I also the expect the above to act weird 'cos anything attempting a "bash --login" type action is going to (for it) unexpectedly fail.

Might work for a single dedicated app though?

User avatar
thagrol
Posts: 5215
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: startx at boot single client and unprivileged user

Sun Jun 13, 2021 11:08 pm

swampdog wrote:
Sun Jun 13, 2021 9:56 pm
I'm not certain as to your precise requirements
Neither am I :D It's part research for my next guide and partly to remove an ugly hack on my DIY combination digital picture frame and clock.
but I've had a play. To summarise (and expect this to fail whenever) - if you lock out the GUI user and change their login shell the GUI still fires up.

Code: Select all

# passwd -l pi
# usermod -s /usr/sbin/nologin pi
..no terminal. More importantly if I'm guessing right, should you ctrl-alt out of the GUI, "pi" can't login and especially ctrl-alt-f1 sees the autologin has failed. ie: set raspi-config such that it tries to autologin the GUI user.

I tried other things including a setuid/setgid C hack but there's just too much faff X has to do. I also the expect the above to act weird 'cos anything attempting a "bash --login" type action is going to (for it) unexpectedly fail.

Might work for a single dedicated app though?
Thanks. That gives me a direction to investigate in terms of enhanced security though I'd probably create a dedicated user rather than us pi. You'd need another user anyway or you're stuck if there's a problem that you need to login to fix.
I'm a volunteer. Take me for granted or abuse my support and I will walk away

All advice given is based on my experience. it worked for me, it may not work for you.
Need help? https://github.com/thagrol/Guides

swampdog
Posts: 718
Joined: Fri Dec 04, 2015 11:22 am

Re: startx at boot single client and unprivileged user

Mon Jun 14, 2021 12:09 am

thagrol wrote:
Sun Jun 13, 2021 11:08 pm
swampdog wrote:
Sun Jun 13, 2021 9:56 pm
I'm not certain as to your precise requirements
Neither am I :D It's part research for my next guide and partly to remove an ugly hack on my DIY combination digital picture frame and clock.
but I've had a play. To summarise (and expect this to fail whenever) - if you lock out the GUI user and change their login shell the GUI still fires up.

Code: Select all

# passwd -l pi
# usermod -s /usr/sbin/nologin pi
..no terminal. More importantly if I'm guessing right, should you ctrl-alt out of the GUI, "pi" can't login and especially ctrl-alt-f1 sees the autologin has failed. ie: set raspi-config such that it tries to autologin the GUI user.

I tried other things including a setuid/setgid C hack but there's just too much faff X has to do. I also the expect the above to act weird 'cos anything attempting a "bash --login" type action is going to (for it) unexpectedly fail.

Might work for a single dedicated app though?
Thanks. That gives me a direction to investigate in terms of enhanced security though I'd probably create a dedicated user rather than us pi. You'd need another user anyway or you're stuck if there's a problem that you need to login to fix.
Yes, another account definitely required. I had my usual "foo" a/c which I was ssh logged into to make the changes. I just realised the above test was on a 64bit rpi but it should make no difference. One thought, in case you haven't noticed yet, is a different user GUI does have some quirks. If I have an rpi autoboot into GUI "foo" it is still referencing "/etc/xdg/lxsession/LXDE-pi/autostart" so there's something to be investigated there. Something hard coded would be my first guess: creating "/etc/xdg/lxsession/LXDE-foo" has no effect but admittedly this isn't my area so could be cockpit error. Should something want root privileges the "pi" user is the only choice in the password menu (which won't work while "pi" is locked by passwd).

I happen to use NoMachine for remote connections. If I have it make a connection to "foo" when the GUI isn't running, it creates a virtual desktop (handy) but the resultant desktop is completely different. I can't check atm but iirc you may even get the option of "root" in addition to "pi" in the password menu.

pidd
Posts: 2296
Joined: Fri May 29, 2020 8:29 pm
Location: Wirral, UK
Contact: Website

Re: startx at boot single client and unprivileged user

Mon Jun 14, 2021 2:39 am

swampdog wrote:
Mon Jun 14, 2021 12:09 am
If I have an rpi autoboot into GUI "foo" it is still referencing "/etc/xdg/lxsession/LXDE-pi/autostart" so there's something to be investigated there.
That is ok, LXDE-pi is referring to the Raspberry Pi computer, not the user Pi.

User avatar
thagrol
Posts: 5215
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: startx at boot single client and unprivileged user

Mon Jun 14, 2021 11:30 am

pidd wrote:
Mon Jun 14, 2021 2:39 am
swampdog wrote:
Mon Jun 14, 2021 12:09 am
If I have an rpi autoboot into GUI "foo" it is still referencing "/etc/xdg/lxsession/LXDE-pi/autostart" so there's something to be investigated there.
That is ok, LXDE-pi is referring to the Raspberry Pi computer, not the user Pi.
Yeah. Like anything in /etc it's impact is global. In this case to all users running a desktop.

In essence, it's the GUI equivalent of /etc/profile
I'm a volunteer. Take me for granted or abuse my support and I will walk away

All advice given is based on my experience. it worked for me, it may not work for you.
Need help? https://github.com/thagrol/Guides

swampdog
Posts: 718
Joined: Fri Dec 04, 2015 11:22 am

Re: startx at boot single client and unprivileged user

Mon Jun 14, 2021 11:38 am

pidd wrote:
Mon Jun 14, 2021 2:39 am
swampdog wrote:
Mon Jun 14, 2021 12:09 am
If I have an rpi autoboot into GUI "foo" it is still referencing "/etc/xdg/lxsession/LXDE-pi/autostart" so there's something to be investigated there.
That is ok, LXDE-pi is referring to the Raspberry Pi computer, not the user Pi.
Ah! I suspect that would *never* have occurred to me! :-)

User avatar
jojopi
Posts: 3490
Joined: Tue Oct 11, 2011 8:38 pm

Re: startx at boot single client and unprivileged user

Mon Jun 14, 2021 12:34 pm

thagrol wrote:
Sun Jun 13, 2021 4:32 pm
Whether from cron, rc.local or systemd trying to run startx /path/to/program as a user other than root always fails with a permission denied error on the tty. I have a few workarounds but none are ideal:
Normally the user is granted access to their terminal as part of the login process. If you want something to start on a virtual console at boot time, without being a login session, I think it is perfectly fine to set the permissions yourself.

Code: Select all

# As root:
setfacl -m u:user:rw /dev/tty9

# As user:
xinit /usr/bin/xclient -- :9 vt9
The use of tty9 and display :9 means that this should not interfere with any gettys or display managers, including regular use of startx by logged in users.

swampdog
Posts: 718
Joined: Fri Dec 04, 2015 11:22 am

Re: startx at boot single client and unprivileged user

Mon Jun 14, 2021 12:50 pm

Here's another experiment. I left in the initial 'echo's to show what I tried.

Code: Select all

foo@pi20:~ $ cat /wrk/wotzit

#!/bin/bash

NAM=`basename "$0"`

echo SHELL="$SHELL"
echo $-
shopt login_shell && echo "LS=Y" || echo "LS=N"
echo "CMD=""$@"
echo "PPID=""$PPID"
ps -hfp "$PPID" -o pid,ppid,cmd

THINGY=$( \
        id -Gn \
        | egrep -o "(^|[[:space:]])nologin([[:space:]]|$)" \
        | awk '{print $1}' \
)

case "$THINGY" in
        nologin)
        PARENT=`ps -hfp "$PPID" -o cmd`
        case "$PARENT" in
                /bin/login*)
                echo "$THINGY" 1>&2
                exit 1
                ;;

                *)
                /bin/bash "$@"
                ;;
        esac
        ;;

        *)
        /bin/bash "$@"
        ;;
esac

Code: Select all

# groupadd nologin
# usermod -aG nologin pi
# usermod -s /wrk/wotzit pi
# echo "/wrk/wotzit" >> /etc/shells
..prevents autologin, still fires up the GUI (if there is one) whilst allowing the GUI itself to launch a terminal.

User avatar
thagrol
Posts: 5215
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: startx at boot single client and unprivileged user

Mon Jun 14, 2021 2:00 pm

Thanks for the input.

I think I have a reasonable solution:
  1. Configure the OS to boot to command line without auto login.
  2. Install xserver-xorg-legacy:

    Code: Select all

    sudo apt update && sudo apt install -y xserver-xorg-legacy
  3. Configure it:
    1. Code: Select all

      sudo dpkg-reconfigure xserver-xorg-legacy
    2. Select "Anybody"
  4. Create and enable a systemd service. For example:

    Code: Select all

    [Unit]
    Description=test service
    
    [Service]
    Type=simple
    User=pi
    Group=pi
    Restart=always
    ExecStart=/usr/bin/startx /usr/bin/mousepad
    
    [Install]
    WantedBy=multi-user.target
    
  5. Optional step - disable the getty on tty1:

    Code: Select all

    sudo systemctl disable getty@tty1
    Do Not do this if you have not enabled ssh or logins over the serial port.
  6. Reboot.
There's a small window when another user could login and startx but the odds are against it.

Cron or rc.local could be used in place of systemd but you'd lose the automatic restart.

Systemd's DynamicUser=Yes feature might make things more secure but using it causes problems with the log files which I've yet to get to the bottom of.
I'm a volunteer. Take me for granted or abuse my support and I will walk away

All advice given is based on my experience. it worked for me, it may not work for you.
Need help? https://github.com/thagrol/Guides

swampdog
Posts: 718
Joined: Fri Dec 04, 2015 11:22 am

Re: startx at boot single client and unprivileged user

Mon Jun 14, 2021 2:51 pm

I did see mention of xserver-xorg-legacy performance issues (generally, not just on rpi), consequently I ignored that option. Let us know if that turns out to be the case.

Fwiw, after posting I noticed: if I shoved "/usr/bin/startx /usr/bin/xclock" just before the "exit 1" and changed raspi-config to autologin text-only then it does fire up.

User avatar
thagrol
Posts: 5215
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: startx at boot single client and unprivileged user

Mon Jun 14, 2021 4:17 pm

swampdog wrote:
Mon Jun 14, 2021 2:51 pm
I did see mention of xserver-xorg-legacy performance issues (generally, not just on rpi), consequently I ignored that option. Let us know if that turns out to be the case.

Fwiw, after posting I noticed: if I shoved "/usr/bin/startx /usr/bin/xclock" just before the "exit 1" and changed raspi-config to autologin text-only then it does fire up.
In which file?

if you're referring to rc.local then, yes, I'd expect it to work. Partly because it's runing as root and partly as rc.local is attached to the console.
I'm a volunteer. Take me for granted or abuse my support and I will walk away

All advice given is based on my experience. it worked for me, it may not work for you.
Need help? https://github.com/thagrol/Guides

swampdog
Posts: 718
Joined: Fri Dec 04, 2015 11:22 am

Re: startx at boot single client and unprivileged user

Mon Jun 14, 2021 5:39 pm

thagrol wrote:
Mon Jun 14, 2021 4:17 pm
swampdog wrote:
Mon Jun 14, 2021 2:51 pm
I did see mention of xserver-xorg-legacy performance issues (generally, not just on rpi), consequently I ignored that option. Let us know if that turns out to be the case.

Fwiw, after posting I noticed: if I shoved "/usr/bin/startx /usr/bin/xclock" just before the "exit 1" and changed raspi-config to autologin text-only then it does fire up.
In which file?
In "wotzit", the dummy login shell..

Code: Select all

foo@pi20:~ $ cat /wrk/wotzit 
#!/bin/bash

NAM=`basename "$0"`

#echo SHELL="$SHELL"
#echo $-
#shopt login_shell && echo "LS=Y" || echo "LS=N"
#echo "CMD=""$@"
#echo "PPID=""$PPID"
#ps -hfp "$PPID" -o pid,ppid,cmd

THINGY=$( \
	id -Gn \
	| egrep -o "(^|[[:space:]])nologin([[:space:]]|$)" \
	| awk '{print $1}' \
)

case "$THINGY" in
	nologin)
	PARENT=`ps -hfp "$PPID" -o cmd`
	case "$PARENT" in
		/bin/login*)
#		echo "$THINGY" 1>&2
/usr/bin/startx /usr/bin/xclock
		exit 1
		;;

		*)
		/bin/bash "$@"
		;;
	esac
	;;

	*)
	/bin/bash "$@"
	;;
esac
thagrol wrote:
Mon Jun 14, 2021 4:17 pm
if you're referring to rc.local then, yes, I'd expect it to work. Partly because it's runing as root and partly as rc.local is attached to the console.
I did get startx/xclock to fire up from rc.local but there was no actual display initiated. Dunno where X thought it was running. Memory like a sieve - I was probably attempting "sudo su - pi -c startx xclock" but not certain.

drtechno
Posts: 261
Joined: Fri Apr 09, 2021 6:33 pm

Re: startx at boot single client and unprivileged user

Wed Jun 16, 2021 5:30 pm

thagrol wrote:
Sun Jun 13, 2021 4:32 pm
Pi model: any
OS: RPiOS full booting to command line without auto loginn
Aim: a reliable and resonably secure way to run startx /path/to/program at boot as an unprivileged user (i.e. not as root).

Whether from cron, rc.local or systemd trying to run startx /path/to/program as a user other than root always fails with a permission denied error on the tty. I have a few workarounds but none are ideal:
  1. Run as root and hang the consequences.
  2. Run as root and have the program drop its privileges. Not possible if you don't have the program source and the necessary knowledge to modify it. Potential complications with thing like ~, $HOME, $PATH, etc
  3. Autologin to a non-root user's command line then run it from their .bashrc. Obivous problem there is .bashrc runs at every login whether local or remote, GUI or command line. Anyone with physial access running has access to a logged in commandline just by connecting a keyboard. With passwordless sudo in the default OS configuration.
  4. Autologin to a non-root user's desktop and use autostart. Anyone with physial access running has access to a logged in desktop just by connecting a keyboard. With passwordless sudo in the default OS configuration.
  5. Install the xserver-xorg-legacy package and configure it so anybody can start the X server. The downside here is that anybody can start the X server on the console as long as it isn't running and they have login credential to the box.
I'm currently leaning towards the last method, possibly combined with reconfiguring xserver-xorg-legacy to restrict access once the desired program has started.

But I'd like to know if there is a more secure and more reliable method.

Before anyone suggests a systemd service wantedby and after graphical.target, that won't help. You'll hit a different set of X security issues and potentially still have a logged in desktop running.

The normal method of dealing with this is to create a new user, but not be part of the group "root" and if the system has it, "sudo-ers"

I am trying to figure out how to rip out their bad security policy. as passwordless sudo would open up the machine to malware attacks so that has to be dealt with before I can make one as a gift for someone that would use it for web browsing.

Do you know a good way of displaying what user groups a user is a member of on the command line?

someone posted on the thread I asked on how to disable the passwordless sudo:

Code: Select all

Delete /etc/sudoers.d/010_pi-nopasswd
so I'm going to try that to see if the policy goes back to normal.

bls
Posts: 1565
Joined: Mon Oct 22, 2018 11:25 pm
Location: Seattle, WA

Re: startx at boot single client and unprivileged user

Wed Jun 16, 2021 5:41 pm

drtechno wrote:
Wed Jun 16, 2021 5:30 pm

Do you know a good way of displaying what user groups a user is a member of on the command line?
Like this.

Code: Select all

bls@p82~> groups pi
pi : pi adm dialout cdrom sudo audio video plugdev games users input netdev spi i2c gpio
bls@p82~> 
Pi tools:
Quickly and easily build customized-just-for-you SSDs/SD Cards: https://github.com/gitbls/sdm
Easily run and manage your network's DHCP/DNS servers on a Pi: https://github.com/gitbls/ndm
Easy and secure strongSwan VPN installer/manager: https://github.com/gitbls/pistrong
Lightweight Virtual VNC Config: https://github.com/gitbls/RPiVNCHowTo

swampdog
Posts: 718
Joined: Fri Dec 04, 2015 11:22 am

Re: startx at boot single client and unprivileged user

Wed Jun 16, 2021 7:04 pm

drtechno wrote:
Wed Jun 16, 2021 5:30 pm
Do you know a good way of displaying what user groups a user is a member of on the command line?

It's the only way I know. :-) In addition to 'groups' there's also 'id' command.
drtechno wrote:
Wed Jun 16, 2021 5:30 pm
someone posted on the thread I asked on how to disable the passwordless sudo:

Code: Select all

Delete /etc/sudoers.d/010_pi-nopasswd
so I'm going to try that to see if the policy goes back to normal.
It should, or just remove NOPASSWD. I haven't tested thoughly in the GUI but it'll pop up an auth dialog: it does when I've got a "foo" user desktop running anyway for 'gparted' but not for 'raspi-config'.

I pop this on my desktop PC and a couple of server rpi's..

Code: Select all

foo@pi18:~ $ sudo cat /etc/sudoers.d/000_foo-noreboot 
Cmnd_Alias FOO = /sbin/shutdown, \
	/sbin/poweroff, /usr/bin/poweroff, \
	/sbin/reboot, /usr/bin/reboot

foo@pi18:~ $ sudo cat /etc/sudoers.d/010_foo-nopasswd 
foo	ALL=(ALL)	NOPASSWD:ALL,!FOO
..not for security: I log into a ton of boxes and it stops me accidentally doing it in the wrong console. You might want to put 'raspi-config' in there. You don't have to call the command alias "FOO" btw!

User avatar
thagrol
Posts: 5215
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: startx at boot single client and unprivileged user

Wed Jun 16, 2021 8:03 pm

drtechno wrote:
Wed Jun 16, 2021 5:30 pm
The normal method of dealing with this is to create a new user, but not be part of the group "root" and if the system has it, "sudo-ers"
Been there, done that, didn't work. If it had I'd be using nobody:nogroup

Yes, that stops user ecks from gaining elevated privileges but it doesn't solve the other problem: calling start /path/to/program as ecks from rc.local, cron, or a systemd service.

Use of a user with restricted rights was implied in options 3 & 4 of my OP.
I'm a volunteer. Take me for granted or abuse my support and I will walk away

All advice given is based on my experience. it worked for me, it may not work for you.
Need help? https://github.com/thagrol/Guides

drtechno
Posts: 261
Joined: Fri Apr 09, 2021 6:33 pm

Re: startx at boot single client and unprivileged user

Thu Jun 17, 2021 7:09 pm

thagrol wrote:
Wed Jun 16, 2021 8:03 pm

Yes, that stops user ecks from gaining elevated privileges but it doesn't solve the other problem: calling start /path/to/program as ecks from rc.local, cron, or a systemd service.

Use of a user with restricted rights was implied in options 3 & 4 of my OP.
If its executing inside cron, then its always root, unless the entry is otherwise states differently.

something gaining access through rc.local would be embedded credentials inside firmware. last known one of those was the D-Link DCS-2121 camera : https://cve.mitre.org/cgi-bin/cvename.c ... -2010-4965

systemd service was added on for plug and play written by RedHat. That has a security flaw in it that makes it susceptible to flood attacks. Redhat fixed its version for itself a few years ago, but I don't know if the patch was implemented by the other distributions that use system.d. But looking at the CVE file, I can see why the web servers in the server farms don't use system.d other than plug and play is not needed: https://cve.mitre.org/cgi-bin/cvekey.cg ... md+service

Another thing I will have to look at is the group "users" as that is not normally a group in debian distributions.

User avatar
thagrol
Posts: 5215
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: startx at boot single client and unprivileged user

Fri Jun 18, 2021 11:08 am

drtechno wrote:
Thu Jun 17, 2021 7:09 pm
thagrol wrote:
Wed Jun 16, 2021 8:03 pm

Yes, that stops user ecks from gaining elevated privileges but it doesn't solve the other problem: calling start /path/to/program as ecks from rc.local, cron, or a systemd service.

Use of a user with restricted rights was implied in options 3 & 4 of my OP.
If its executing inside cron, then its always root, unless the entry is otherwise states differently.
Only if run from root's crontab. The cron daemon may be runing as root but processes in a normal user's crontab are run by that user. I'd expect someone claiming years of linux experience to know that.
something gaining access through rc.local would be embedded credentials inside firmware. last known one of those was the D-Link DCS-2121 camera : https://cve.mitre.org/cgi-bin/cvename.c ... -2010-4965

systemd service was added on for plug and play written by RedHat. That has a security flaw in it that makes it susceptible to flood attacks.
Redhat fixed its version for itself a few years ago, but I don't know if the patch was implemented by the other distributions that use system.d. But looking at the CVE file, I can see why the web servers in the server farms don't use system.d other than plug and play is not needed: https://cve.mitre.org/cgi-bin/cvekey.cg ... md+service

Another thing I will have to look at is the group "users" as that is not normally a group in debian distributions.
That's not relevant to either the original question or to the post you quoted.
I'm a volunteer. Take me for granted or abuse my support and I will walk away

All advice given is based on my experience. it worked for me, it may not work for you.
Need help? https://github.com/thagrol/Guides

User avatar
rpdom
Posts: 18856
Joined: Sun May 06, 2012 5:17 am
Location: Chelmsford, Essex, UK

Re: startx at boot single client and unprivileged user

Fri Jun 18, 2021 11:48 am

thagrol wrote:
Fri Jun 18, 2021 11:08 am
drtechno wrote:
Thu Jun 17, 2021 7:09 pm
thagrol wrote:
Wed Jun 16, 2021 8:03 pm

Yes, that stops user ecks from gaining elevated privileges but it doesn't solve the other problem: calling start /path/to/program as ecks from rc.local, cron, or a systemd service.

Use of a user with restricted rights was implied in options 3 & 4 of my OP.
If its executing inside cron, then its always root, unless the entry is otherwise states differently.
Only if run from root's crontab. The cron daemon may be running as root but processes in a normal user's crontab are run by that user. I'd expect someone claiming years of linux experience to know that.
I think that "drtechno" is referring to the /etc/crontab file for some reason. Not the user crontabs.
Unreadable squiggle

Return to “Advanced users”