RE: policy rpm %post script encounters avc violations

[Johnson, Richard]

On Tue, 26 Aug 2008 8:05 PM
"Paul Howarth" <paul(a)city-fan.org&gt; wrote: 

>  On Tue, 26 Aug 2008 16:02:15 -0400
>  "Johnson, Richard" <Richard.Johnson(a)stratus.com&gt; wrote:
>
>  > When installing a policy rpm, one cannot log the install activity 
w/o
>  > generating avc errors.  For example:
>  > 
>  > rpm -i lsb-ft-asn-selinux > /var/log/rpm-update.log
>  > 
>  > produces the following violation:
>  > 
>  > type=SYSCALL msg=audit(1219774608.030:789): arch=c000003e syscall=59
>  > success=yes exit=0 a0=be952e0 a1=be93390 a2=be958f0 a3=8 items=0
>  > ppid=2848 pid=2875 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
>  > sgid=0 fsgid=0 tty=ttyS1 ses=2 comm="restorecon"
>  > exe="/sbin/restorecon"
subj=root:system_r:restorecon_t:s0-s0:c0.c1023
>  > key=(null) type=AVC msg=audit(1219774608.030:789): avc:  denied
>  > { write } for pid=2875 comm="restorecon"
>  > path="/var/log/rpm-update.log" dev=md2 ino=2694055
>  > scontext=root:system_r:restorecon_t:s0-s0:c0.c1023
>  > tcontext=root:object_r:var_log_t:s0 tclass=file
>  > 
>  > The problems seems to stem from recording the %post script's 
attempts
>  > to relabel files affected by the policy, specifically:
>  > 
>  > /sbin/restorecon -F -R -v /opt/ft/sbin/sra_alarm;
>  > /sbin/restorecon -F -R -v /etc/opt/ft/asn;
>  > /sbin/restorecon -F -R -v /var/opt/ft/asn;
>  > /sbin/restorecon -F -R -v /var/opt/ft/log;
>  > 
>  > Is there any way to preserve the logging w/o disabling selinux for 
the
>  > duration of the install?
>  > 
>  > FWIW, the rpm commands are executed from a bash script.
>
>  You could try logging to a file with a different context type, e.g.
>
>  rpm -i lsb-ft-asn-selinux > /tmp/rpm-update.log
>
>  and then move the resulting file to /var/log if you need it to be
>  there. I'm not sure if restorecon_t can write to temp files but it's
>  probably more likely that writing to var_log_t, which is currently
>  what's being denied. 
I wish it were as simple as using a tmp_t:file.  I tried that, and the
answer's no.

I suppose the general process would be a script that: 
 - creates a temporary file
 - label it--silently, to avoid an avc logging the activity
 - do the restorecon.
 - cat the temporary file to stdout.
 - and the various complications of cleanup should an error occur
 - and replicating the encapsulation in both %post and %postun scripts.


For my understanding:  If it were to work, what's gained by restricting
restorecon from logging directly? 

--rich