policy rpm %post script encounters avc violations

[Johnson, Richard]

On Tue, 26 Aug 2008 8:05 PM
"Paul Howarth" <paul at city-fan.org> wrote: 

> On Tue, 26 Aug 2008 16:02:15 -0400
> "Johnson, Richard" <Richard.Johnson at stratus.com> 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