Re:Systemd can't handle the process privilege for username s...
by JdeBP on Sunday July 02, 2017 @06:28AM
(#14681857)
I am going with ...
root # chpst -u 0zero id
uid=1462(0zero) gid=1481(0zero) groups=1481(0zero)
root # setuidgid 0zero id
uid=1462(0zero) gid=1481(0zero) groups=1481(0zero)
root #
... I would not; I would. Both of these use the getpwnam() library function of course. Their behaviours are ... root # chpst -u 0day id
chpst: fatal: unable to get password/group file entry: file does not exist
root # setuidgid 0day id
setuidgid: FATAL: 0day: No such user.
root #
... to abend when the account name is not found rather than continue on as the superuser without dropping privileges ...* http://jdebp.eu./Softwares/nosh/guide/setuidgid.html
* http://cr.yp.to/daemontools/setuidgid.html
* http://untroubled.org/daemontools-encore/setuidgid.8.html
... as is documented in their user manuals, resulting in ...
root # system-control convert-systemd-units ./0day.service
root # install -d /home/0day
root # ln -s /etc/service-bundles/services/sysinit-log 0day/log
root # system-control start 0day
root # system-control status 0day
/var/local/sv/0day:
State : failed since 2017-07-02 11:14:17 +0100; 0s ago
Main PID: 80083
Started: exit 0 at 2017-07-02 11:13:35 +0100; 42s ago
Ran: exit 111 at 2017-07-02 11:14:17 +0100; 0s ago
Config : enabled
2017-07-02 11:14:17.130870725 setuidgid: FATAL: 0day: No such user.
2017-07-02 11:14:17.247334398 setuidgid: FATAL: 0day: No such user.
2017-07-02 11:14:17.363857132 setuidgid: FATAL: 0day: No such user.
2017-07-02 11:14:17.481175128 setuidgid: FATAL: 0day: No such user.
2017-07-02 11:14:17.598958702 setuidgid: FATAL: 0day: No such user.
root #
... the 0day service from the headlined bug report failing to start.
Re:Systemd can't handle the process privilege for username s...
by ArneBab on Sunday July 02, 2017 @06:41AM
(#14681897)
Or maybe 0pointer → http://0pointer.net/imprint
You're running a SaaS which spawns restricted demons/containers per customer, separating the users by assigning them local user accounts. One day, user "0zero" registers and their account has access to your whole environment. Would you expect this? Would you not classify this as a security issue?