Bug 198157 - amanda amrecover has selinux constraints too tight
Summary: amanda amrecover has selinux constraints too tight
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted   
(Show other bugs)
Version: 5
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2006-07-10 12:12 UTC by Jonathan Larmour
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version: 2.3.6-3.fc5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-23 19:40:14 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Jonathan Larmour 2006-07-10 12:12:54 UTC
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
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,

allow amanda_recover_t devpts_t:chr_file { read write getattr ioctl };
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):



Comment 1 Daniel Walsh 2006-07-10 15:44:11 UTC
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.

Comment 2 Jonathan Larmour 2006-07-11 17:31:27 UTC
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 :-).



Comment 3 Daniel Walsh 2006-08-11 19:26:12 UTC
Fixed in  selinux-policy-2.3.6-3.fc5

Comment 4 Jonathan Larmour 2006-09-23 19:40:14 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.