Hacker News Reader

Comment by RjQoLCOSwiIKfpm | Hacker News Reader

The article seems quite unclear about potential consequences of using su this way.

I typically use su to run some program in its own user account to ensure:

- it has its own homedir and doesn't fill mine with garbage.

- there is some level of isolation from the rest of the system for security, a basic "jail". I'm not trying to protect against targeted attacks from extremely competent threat actors here, but rather trying to stick software into its own user account so it can only access that account, with isolation of the same level as if I had manually logged in to a secondary account.

Can such programs break out of their "jail" when using su?

Or is the author of the article just angry for other reasons?

View on HN

The article does not talk about security problems. It's about whether your daemon works correctly.

1. Depending on the environment, process supervision can break if there is an unexpected process sitting between the supervisor and the supervisee. The article describes how the switch to PAM forced the introduction of an in-the-middle process responsible for closing the PAM session. The old su used exec, which avoids an in-the-middle process.

2. Su uses the shell of the target user, and will outright not work if the target user has a "nologin" shell.

The article goes on to mention correct workarounds for this like daemontools setuidguid, Runit chpst or just rolling your own exec wrapper.

Yes, the program can likely setuid to the original user with su, as the session is the parent session and still active.

This is not a behavior you want of a jail. Use chroot, LXC or your own setuid wrapper that removes the privilege.

Well, os.setuid and os.seteuid in Python give me "PermissionError: [Errno 1] Operation not permitted". Do you have an example of how this could be done?

Every process in your system either still has an ancestor that is still running and has superuser privileges. Either because that was the real ancestor, or else because that ancestor is PID 1 due to reparenting.

A process cannot use its existing ancestral sessions to gain control of their account.

> angry

Seems like an unnecessary assumption.

Reply on news.ycombinator.com