Bug 1357859
| Summary: | guest_t can run sudo | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Lukas Vrabec <lvrabec> | ||||
| Component: | openssh | Assignee: | Jakub Jelen <jjelen> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Stefan Kremen <skremen> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 7.3 | CC: | dominick.grift, dwalsh, extras-qa, jjelen, lvrabec, mgrepl, mmalik, nmavrogi, plautrba, pvrabec, qe-baseos-security, rvdwees, skremen, ssekidde, szidek | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | openssh-6.6.1p1-29.el7 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | 1357857 | ||||||
| : | 1376826 (view as bug list) | Environment: | |||||
| Last Closed: | 2016-11-03 20:20:29 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | 1356245, 1357857, 1357860 | ||||||
| Bug Blocks: | 1376826, 1378463 | ||||||
| Attachments: |
|
||||||
|
Comment 2
Jakub Jelen
2016-07-20 11:16:12 UTC
It looks like Lukas didn't actually add the setcap rule, only the setpcap, as it looks from the linked diff. And to the SSH client policy?
> + # SSH client local policy
> ++allow ssh_t self:capability { setpcap setuid setgid dac_override dac_read_search };
Shouldn't it come to the sshd_t as explained in the above mentioned comment?
Stefan, this is expected behavior. The issue was that the guest_u could run the sudo when the boolean selinuxuser_use_ssh_chroot was enabled. Reading the /etc/shadow is out of the scope of this bug. It was just an arbitrary operation requiring superuser privileges. AFAIK, there was no real exploit (Simon, Lukas, correct me if I am wrong), because the context of guest_u didn't allow to progress much further from sudo, but mitigating even the ability to start sudo was the intention of this bug (removing setuid, setgid permissions from the confined users and handling the chroot in ssh using linux capabilities). Thanks Jakub for explanation. 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. https://rhn.redhat.com/errata/RHSA-2016-2588.html |