Red Hat Bugzilla – Bug 972969
spacewalk-report ssh key should be locked down to only run reports
Last modified: 2013-10-01 06:55:58 EDT
Description of problem: Currently, spacewalk-splice-tool logs in as a user on the spacewalk machine via an ssh key, and runs three "spacewalk-report" commands. However, a root user on the SAM host can use the ssh key to obtain a shell on the spacewalk machine, even though the script does not need a full shell.
Instead, the remote login should be constrained, possibly by setting the command in authorized_keys on the spacewalk host to only return spacewalk-report data when the sst key is used.
Version-Release number of selected component (if applicable): 0.19
How reproducible: every time
Steps to Reproduce:
1. log into SAM host, cat /etc/splice/checkin.conf
2. use values under "spacewalk" section of config to obtain a shell on spacewalk host
Actual results: user is logged in with a shell
Expected results: user gets report data returned and session quits, no shell
Additional info: There are a few ways to solve this problem, authorized_keys is just one of them. If this style of fix is used, the sst code and user setup doc need to be updated.
I think this can be solved with just documentation. I updated the user doc with the following text:
For added security, restrict the user that logins with the ssh key to only running the spacewalk-report command. Do this by prepending the following to the key content in /root/.ssh/authorized_keys:
Added to line 75 in http://splice.pad.engineering.redhat.com/46
Going this route doesn't require any changes to sst.
actually, I had to change sst to no longer specify to run the /usr/bin/spacewalk-report command since it's now confined to run that command in the authorized_keys file on the satellite server.
Verified in spacewalk-splice-tool-0.24-1.el6sam.x86_64
However /etc/splice/checkin.conf still has spacewalk_reports=/usr/bin/spacewalk-report setting which is useless after the hardening (the setting is in ~/.ssh/authorized_keys now)
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.