Re: [systemd-devel] Best way to limit per-user system-wide units
Okay so after mucking around a bit more, I was wondering if the most logical way to solve this problem would be to edit /etc/pam.d/sudo to add pam_systemd.so - would this work? I tried it and couldn't get it to do anything meaningful, but TBH PAM is not my area of expertise. On 14 December 2016 at 15:36, Samuel Williams wrote: > Okay, so tried some more things. > > $ sudo su - http env > This account is currently not available. > > That's because the user has nologin set as the shell. > > So, does that mean it's impossible to use systemctl --user ? > > > > On 14 December 2016 at 13:13, Samuel Williams > wrote: >> Its unfortunately common for popular software to have CVEs, it's a sign of >> an overall healthy environment I think. In any case my original point still >> stands, regarding formal verification. But that's not the main issue here so >> let's not get sidetracked :) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Best way to limit per-user system-wide units
Okay, so tried some more things. $ sudo su - http env This account is currently not available. That's because the user has nologin set as the shell. So, does that mean it's impossible to use systemctl --user ? On 14 December 2016 at 13:13, Samuel Williams wrote: > Its unfortunately common for popular software to have CVEs, it's a sign of > an overall healthy environment I think. In any case my original point still > stands, regarding formal verification. But that's not the main issue here so > let's not get sidetracked :) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Best way to limit per-user system-wide units
Its unfortunately common for popular software to have CVEs, it's a sign of an overall healthy environment I think. In any case my original point still stands, regarding formal verification. But that's not the main issue here so let's not get sidetracked :) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Best way to limit per-user system-wide units
Am 14.12.2016 um 00:08 schrieb Samuel Williams: Well, given I opened the PR, I'd hope the chance is very low -- at least, no more than sudo. Sudo verifies the configuration using a regular language. It doesn't mean you can't shoot yourself in the foot, but it makes it pretty damn hard. JavaScript on the other hand.. a logic bug or error in the code might bork the entire system and since it's turing complete it's impossible to test for this condition before it occurs. Which is why sudo was designed the way it was i see https://www.google.com/search?q=sudo+CVE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Best way to limit per-user system-wide units
> Well, given I opened the PR, I'd hope the chance is very low -- at least, no > more than sudo. Sudo verifies the configuration using a regular language. It doesn't mean you can't shoot yourself in the foot, but it makes it pretty damn hard. JavaScript on the other hand.. a logic bug or error in the code might bork the entire system and since it's turing complete it's impossible to test for this condition before it occurs. Which is why sudo was designed the way it was. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Best way to limit per-user system-wide units
On Wed, 14 Dec 2016, Samuel Williams wrote: [...] The nice thing about sudo is that it is a general framework that is well tested, well documented, and works everywhere... polkit, less so. Even with the best of intentions, looking at how well people have managed to script security features (e.g. look at the whole ethereum contract fiasco), stuff in that PR makes me a bit worried. What's the chance someone screws up a security rule? JavaScript is only a small step up from PHP in terms of semantic rigour, so I'd be concerned about that too. Well, given I opened the PR, I'd hope the chance is very low -- at least, no more than sudo. At least the JavaScript is given a minimal standard library, it's sandboxed and run as an unprivileged user. :-p I always think the problem with sudo is that it turns "mere bugs" into security vulnerabilities. systemctl was designed to be run both by root and by users -- but if there's a bug in it, then such a bug does not on its own grant users any more privileges than they would have normally. It wasn't designed to be run _as_ root _by_ a user; so using systemctl through sudo is effectively using it outside its design parameters. Anyhow, this isn't really the right time or place to discuss sudo vs other authentication frameworks. I'm afraid I don't have any better suggestions though. - Michael ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Best way to limit per-user system-wide units
So, I was playing around with sudo and found the following: % env | grep XDG XDG_SESSION_ID=4 XDG_RUNTIME_DIR=/run/user/1000 % sudo -u http env | grep XDG ... nothing... Found this: http://stackoverflow.com/questions/28809235/how-to-get-xdg-variables-with-sudo Of course, using a login shell is not feasible: % sudo -iu http env -nologin: invalid option -- 'c' That's a deliberate security consideration. Ideas? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Best way to limit per-user system-wide units
> Putting aside the issue of having users link their own units into the system > configuration -- as pointed out else in this thread, that comes with a *lot* > of security issues -- you don't even need sudo or su to allow users to > control system units. You are absolutely correct. The users have control to the software that's being run on the system in any case, if they are malicious it's game over. Nothing can prevent that. On production, the only user is `ci` anyway. It could be that we run the foreman export task as this user which has password-less sudo. It's not feasible to manage 20 independent passwords for 20 deployments. SSH keys are the best option in my experience, but welcome any suggestions here. What I'm more interested in doing is *protecting the http user so that if someone, somehow, does manage to crack the web application, they can't get root*. Right now, that is possible by allowing sudo systemctl link or equivalent which is why I'm here discussing the issue. We'd ideally like to keep http, http everywhere (i.e. no obvious/deliberate ability for privilege escalation). The nice thing about sudo is that it is a general framework that is well tested, well documented, and works everywhere... polkit, less so. Even with the best of intentions, looking at how well people have managed to script security features (e.g. look at the whole ethereum contract fiasco), stuff in that PR makes me a bit worried. What's the chance someone screws up a security rule? JavaScript is only a small step up from PHP in terms of semantic rigour, so I'd be concerned about that too. As I said, ideally we'd be able to enforce this logic directly within /etc/systemd/system/$user, but if that's not possible, `systemd --user` is a close 2nd given what I've seen. We just need to figure out how to make it work in a sudo environment (could necessitate a change to /etc/sudoers which would be fine). Thanks for your input. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Best way to limit per-user system-wide units
Reindl, thanks for your continued help.
> what *exact* problem are you trying to solve - don#t come with the solution
> "doing that as systemd-unit" - explain the problem what you are trying to
> solve not the solution you think is good!
Okay, our website deployment process is something like this.
Developers (or ci) have a password-less (ssh key only) account on the
server (either production or development).
- They push code into a repository on the production server using git.
They are a member of the group of the .git directory (usually http),
the code is pushed as the website user/group so that all users can do
it without borking up the permissions on files.
- The git repository runs a post-receive hook as that user (e.g. "bob"
or "ci"). It performs several tasks as that user, but the primary
task, once the source code is checked out and updated, is to deploy
any changes.
- The way this works, is that `rake deploy` is run in the web
directory. This task does quite a bit of stuff, including updating
foreman tasks.
- Foreman can generate tasks in lots of different ways, but we prefer
systemd units. We essentially run `sudo systemctl stop
$website.target`, `foreman export ...` and then `sudo systemctl start
$website.target`.
Exact foreman command: sh("bundle", "exec", "foreman", "export",
"systemd", SYSTEMD_UNIT_PATH, "-a", DATABASE_NAME, "-u",
`whoami`.chomp!)
sudo is set up to allow developers to do pretty much anything without
a password, while the website user is locked down pretty tightly.
Ideally, we don't expose root via the ability to arbitrarily load
systemd tasks.
For me, the ideal solution would be something like a per-user global
systemd unit directory. In theory, systemd would run units in that
directory locked down to that specific user. But, being in the global
context, would allow tasks to depend on each other. If it was kept in
a separate directory, it would simplify deployment and changes.
The next best solution as far as I can see, is to use systemd --user.
But this has a number of downsides - firstly out of the box it doesn't
work with a sudo environment:
Logged in as a dev user:
% systemd-run --user sleep 10
Running as unit: run-r341b245b4e324a2fa9aec1c272d8abea.service
% sudo -u http !!
sudo -u http systemd-run --user sleep 10
Failed to create bus connection: No such file or directory
% su -c "sudo -u http systemd-run --user sleep 10" - http
Password:
su: Authentication failure
Secondly, I've got concerns about how reliable this is in terms of
tasks that need to start at boot, and might have dependencies on
system-level tasks. How does `loginctl enable-linger http` work and is
it reliable?
Thanks for any insight, ideas, or suggestions you might have to
improve this process.
Kind regards
Samuel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Best way to limit per-user system-wide units
On Wed, 14 Dec 2016, Samuel Williams wrote: Reindl, I understand where you are coming from, but I'm not sure I understand what the alternative you are proposing is, are you suggesting I use su? Putting aside the issue of having users link their own units into the system configuration -- as pointed out else in this thread, that comes with a *lot* of security issues -- you don't even need sudo or su to allow users to control system units. systemd uses polkit for authentication, and you can write polkit rules to grant access to particular operations on particular units to particular users or groups. Unfortunately this feature isn't particularly well-documented at the moment, but you can take a look at an example at the top of: https://github.com/systemd/systemd/pull/1159 More details on these rule files are in the polkit(8) manpage, under Authorization Rules. - Michael ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Best way to limit per-user system-wide units
Am 13.12.2016 um 22:40 schrieb Samuel Williams: Reindl, thanks for your ideas. So, I log in as me "bob", but I want to run a task as http, e.g. sudo -u http git checkout -f What do you propose as the alternative? "man su" - the environment is completly different it's also different between "su" and "su -" but how is *that* a systemd-unit job and what do you think to gain when you work all the time with sudo (in the worst case even without a password) P.S: get rid of reply-all, i donät need two copies of every list mail one responds to On 14 December 2016 at 09:49, Reindl Harald wrote: Am 13.12.2016 um 21:41 schrieb Samuel Williams: I wanted to use systemd --user but had trouble getting it to run via sudo- seemed like the environment wasn't getting set up correctly. Any ideas? get rid of sudo and re-consider everything where you are using sudo/su ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Best way to limit per-user system-wide units
Am 13.12.2016 um 22:48 schrieb Samuel Williams: Reindl, I understand where you are coming from, but I'm not sure I understand what the alternative you are proposing is, are you suggesting I use su? su -c "whatever" - user at least preserves the environement i still don't get what your (stripped and without context) example has to do with a systemd-unit there are no "per-user system-wide units" what *exact* problem are you trying to solve - don#t come with the solution "doing that as systemd-unit" - explain the problem what you are trying to solve not the solution you think is good! On 14 December 2016 at 10:45, Reindl Harald wrote: Am 13.12.2016 um 22:40 schrieb Samuel Williams: Reindl, thanks for your ideas. So, I log in as me "bob", but I want to run a task as http, e.g. sudo -u http git checkout -f What do you propose as the alternative? "man su" - the environment is completly different it's also different between "su" and "su -" but how is *that* a systemd-unit job and what do you think to gain when you work all the time with sudo (in the worst case even without a password) P.S: get rid of reply-all, i donät need two copies of every list mail one responds to On 14 December 2016 at 09:49, Reindl Harald wrote: Am 13.12.2016 um 21:41 schrieb Samuel Williams: I wanted to use systemd --user but had trouble getting it to run via sudo- seemed like the environment wasn't getting set up correctly. Any ideas? get rid of sudo and re-consider everything where you are using sudo/su ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Best way to limit per-user system-wide units
Reindl, I understand where you are coming from, but I'm not sure I understand what the alternative you are proposing is, are you suggesting I use su? On 14 December 2016 at 10:45, Reindl Harald wrote: > > > Am 13.12.2016 um 22:40 schrieb Samuel Williams: >> >> Reindl, thanks for your ideas. >> >> So, I log in as me "bob", but I want to run a task as http, e.g. sudo >> -u http git checkout -f >> >> What do you propose as the alternative? > > > "man su" - the environment is completly different > > it's also different between "su" and "su -" > > but how is *that* a systemd-unit job and what do you think to gain when you > work all the time with sudo (in the worst case even without a password) > > P.S: get rid of reply-all, i donät need two copies of every list mail one > responds to > > >> On 14 December 2016 at 09:49, Reindl Harald >> wrote: >>> >>> >>> >>> Am 13.12.2016 um 21:41 schrieb Samuel Williams: I wanted to use systemd --user but had trouble getting it to run via sudo- seemed like the environment wasn't getting set up correctly. Any ideas? >>> >>> >>> get rid of sudo and re-consider everything where you are using sudo/su > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Best way to limit per-user system-wide units
Reindl, thanks for your ideas. So, I log in as me "bob", but I want to run a task as http, e.g. sudo -u http git checkout -f What do you propose as the alternative? On 14 December 2016 at 09:49, Reindl Harald wrote: > > > Am 13.12.2016 um 21:41 schrieb Samuel Williams: >> >> I wanted to use systemd --user but had trouble getting it to run via >> sudo- seemed like the environment wasn't getting set up correctly. Any >> ideas? > > > get rid of sudo and re-consider everything where you are using sudo/su > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Best way to limit per-user system-wide units
Am 13.12.2016 um 21:41 schrieb Samuel Williams: I wanted to use systemd --user but had trouble getting it to run via sudo- seemed like the environment wasn't getting set up correctly. Any ideas? get rid of sudo and re-consider everything where you are using sudo/su ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Best way to limit per-user system-wide units
I wanted to use systemd --user but had trouble getting it to run via sudo- seemed like the environment wasn't getting set up correctly. Any ideas? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Best way to limit per-user system-wide units
On Wed, Dec 14, 2016 at 01:23:14AM +1300, Samuel Williams wrote: > I'd like my http user to be able to install unit files and start/stop them. > > Starting and stopping them is fairly easy with a sudo rule.. > > But adding them is a bit trickier. I could also use sudo but it seems > fairly specific. > > Is there some way to add a new directory, e.g. > /etc/systemd/system/http which has permissions specific for http user? > > I can install targets/services/etc into that directory and then use > sudo systemctl start/stop Keep in mind that allowing user to define services is basically giving him root permissions (user can create unit with ExecStart=/usr/bin/rm -rf /)*. So there's no point in separating directories. You can make this safer by using user instance units. You get canonical path with this solution: ~/.config/systemd/user/ * I know about --no-preserve-root -- Tomasz Torcz "Never underestimate the bandwidth of a station xmpp: zdzich...@chrome.plwagon filled with backup tapes." -- Jim Gray ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Best way to limit per-user system-wide units
I will explore using link further. However, in some cases the behaviour is hard to leverage. I'm using foreman to generate systemd files. If I remove an existing target, it will be hard to replicate this.. unless I trash everything before re-linking everything. It's not a very elegant solution. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Best way to limit per-user system-wide units
On Tue, Dec 13, 2016 at 3:52 PM, Samuel Williams wrote: > Hmm, so my local units directory contains business_development.target > which contains > > Wants=business_development-resque-worker-high-priority.target > business_development-resque-worker.target > > But when using systemctl link, neither of these get installed > correctly (and no warning is given when running the > business_development.target). > > Any ideas? "systemctl link" simply links specific unit definition file under /etc/systemd. Of course you need to link every unit definition file you have if you have multiple units. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Best way to limit per-user system-wide units
Before I got to bed. It seems like it would make the most sense for me to be able to namespace unit files. e.g. make a directory such as /etc/systemd/system/http and give that directory suitable permissions. Then, it's simpler to blow away all targets/services in that directory if I need to rewrite them. It would be nice if there was some way to do this with systemd/systemctl. Another option would be to have a config file allowing you to specify alternative directories. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Best way to limit per-user system-wide units
Hmm, so my local units directory contains business_development.target which contains Wants=business_development-resque-worker-high-priority.target business_development-resque-worker.target But when using systemctl link, neither of these get installed correctly (and no warning is given when running the business_development.target). Any ideas? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Best way to limit per-user system-wide units
Thanks Andrei, this is something I will explore. Will this work well if I have targets which have multiple dependencies? i.e. can I just link the top level target? On 14 December 2016 at 01:36, Andrei Borzenkov wrote: > On Tue, Dec 13, 2016 at 3:23 PM, Samuel Williams > wrote: >> I'd like my http user to be able to install unit files and start/stop them. >> >> Starting and stopping them is fairly easy with a sudo rule.. >> >> But adding them is a bit trickier. I could also use sudo but it seems >> fairly specific. >> >> Is there some way to add a new directory, e.g. >> /etc/systemd/system/http which has permissions specific for http user? >> >> I can install targets/services/etc into that directory and then use >> sudo systemctl start/stop >> >> Thanks for any ideas or suggestions. Alternative ways to achieve the >> same thing also welcome. >> > > You can use "systemctl link /path/to/unit/file", this probably is more > friendly for sudo pattern to match only specific /path/to/unit/ > directory. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Best way to limit per-user system-wide units
On Tue, Dec 13, 2016 at 3:23 PM, Samuel Williams wrote: > I'd like my http user to be able to install unit files and start/stop them. > > Starting and stopping them is fairly easy with a sudo rule.. > > But adding them is a bit trickier. I could also use sudo but it seems > fairly specific. > > Is there some way to add a new directory, e.g. > /etc/systemd/system/http which has permissions specific for http user? > > I can install targets/services/etc into that directory and then use > sudo systemctl start/stop > > Thanks for any ideas or suggestions. Alternative ways to achieve the > same thing also welcome. > You can use "systemctl link /path/to/unit/file", this probably is more friendly for sudo pattern to match only specific /path/to/unit/ directory. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Best way to limit per-user system-wide units
I'd like my http user to be able to install unit files and start/stop them. Starting and stopping them is fairly easy with a sudo rule.. But adding them is a bit trickier. I could also use sudo but it seems fairly specific. Is there some way to add a new directory, e.g. /etc/systemd/system/http which has permissions specific for http user? I can install targets/services/etc into that directory and then use sudo systemctl start/stop Thanks for any ideas or suggestions. Alternative ways to achieve the same thing also welcome. Kind regards, Samuel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
