Bug 198157
| Summary: | amanda amrecover has selinux constraints too tight | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jonathan Larmour <jifl-bugzilla> |
| Component: | selinux-policy-targeted | Assignee: | Daniel Walsh <dwalsh> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 2.3.6-3.fc5 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-09-23 19:40:14 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
I don't think amange_recover should even be transitioning from uncofined_t. Try chcon -t bin_t amrecover And try it. I will eliminate the transition if this works. Hi Daniel, Yes, that works. Although clearly someone has provided the amanda_recover_t type, and amanda_recover_exec_t file context for a reason, but I wonder what in that case. You're more likely to know than me, so I'll leave it to you :-). Thanks Jifl Fixed in selinux-policy-2.3.6-3.fc5 I guess nothing more is needed on this bug since that release fixed it. Although the amanda_recover_t and amanda_recover_exec_t contexts are still around which are now redundant. Perhaps something should be fed upstream too. |
Description of problem: When running amrecover to restore a file, there are lots of SElinux restrictions the amanda_recover_t type stumbles into. First of all it cannot access the terminal: type=AVC msg=audit(1152529434.817:40885): avc: denied { read write } for pid=32217 comm="amrecover" name="14" dev=devpts ino=16 scontext=user_u:system_r:amanda_recover_t:s0 tcontext=user_u:object_r:devpts_t:s0 tclass=chr_file This happens even when logging on as a proper tty (tty1,2,3,etc.) as well as a su from an xterm. Some old discussion from an selinux list implied there may be some sysadm_tty_device_t context that the terminal device is meant to be set to by the login program, although that information may be obsolete. Either way, it's not possible to even start amrecover without one of these policy tweaks, either: allow amanda_recover_t devpts_t:chr_file { read write getattr ioctl }; or amanda_run_recover( unconfined_t, system_r, devpts_t ); After that, doing an "ls" also reported a slew of problems related to trying to run /bin/bash and its own startup. The pager (in my case less) also needs to control the terminal, and read /usr/share/terminfo/x/xterm. I found I needed to add the following policy tweak too: allow amanda_recover_t devpts_t:dir { search }; allow amanda_recover_t sbin_t:dir { search }; allow amanda_recover_t usr_t:file { read }; Even now, I'm not sure that if I tried to recover a file, that it wouldn't fall foul of something else. I'm thinking that the selinux policy for amanda_recover_t may be too tight in general though. Version-Release number of selected component (if applicable): selinux-policy-targeted-2.2.43-4.fc5 amanda-client-2.4.5p1-3.2 (FC5)