At least one security benchmark (CIS RHEL Benchmark, v1.1.2, available from https://benchmarks.cisecurity.org/tools2/linux/CIS_RHEL_5.0-5.1_Benchmark_v1.1.2.pdf , section 6.3 p62 ) recommends that this file be made inaccessible to non-root users.

The approach taken by this script of:
-create temp file
-mv temp file over previous file
-assign specific permissions (overriding secured umask)

makes it inconvenient to achieve this control. Our security standard, maintained by a separate group, is based on the CIS benchmark. So far we have a package which implements our internal standard, however in some cases it becomes unnecessarily complex, as some of the files that need to be modified are not marked as config(noreplace) in the original package, and so we already have a number of triggers to re-fix files that need fixing (e.g. /etc/issue, /etc/login.defs). This will be another one I need to add ...


Alternatively, could the temporary file not instead be copied over the existing file, thus preserving all file meta-data:
-attributes (such as SELinux context)
-ACLs
-permissions

Also, why are the permissions explicitly set (to what they would be by default), without any configurability? If a different umask is set (ours is 077 for root by requirement), it should be obeyed by default, or a mechanism to control the permissions that will be set should be provided.

However, copying and deleting the temp tile, instead of moving it, would fix all the current problems (besides possibly the initial labeling).

Since this has been split out of the 'rpm' package itself in RHEL6 though, for now we will jut not install the cron subpackage ...

Making /var/log/rpmpkgs* unreadable by regular users doesn't accomplish a whole lot since those users can just do 'rpm -qa' to get actually up-to-date information about the currently installed packages.

But sure we can tweak the dumb script again to cater to the selinux policy of the day.

Actually, it is necessary to call restorecon. Copying into /var/log doesn't give /var/log/rpmpkgs correct context because /var/log/rpmpkgs should have context different from /var/log directory itself.

Therefore you should:
mv temp_file /var/log/rpmpkgs
restorecon /var/log/rpmpkgs
chmod 644 /var/log/rpmpkgs

Could you please respin as soon as possible?

To sum it up. We will stick with cron_log_t context and update permissions to 644. ATM we do not need another respin.

But also change is required in selinux-policy, filed as Bug 820535

Btw, I have tested it with rpm-cron-4.8.0-27.el6.noarch:

[root@auto-x86-64-002 etc]# ls -Z /var/log/rpmpkgs
-rw-r--r--. root root system_u:object_r:cron_log_t:s0  /var/log/rpmpkgs
[root@auto-x86-64-002 etc]# ls -l /var/log/rpmpkgs
-rw-r--r--. 1 root root 41337 May 10 06:16 /var/log/rpmpkgs

Just make it cron_log_t and be done with it.

(In reply to comment #4)
> Making /var/log/rpmpkgs* unreadable by regular users doesn't accomplish a whole
> lot since those users can just do 'rpm -qa' to get actually up-to-date
> information about the currently installed packages.

Depending on the permissions of /var/lib/rpm.

> But sure we can tweak the dumb script again to cater to the selinux policy of
> the day.

Looks like we'll just make our internal initial configuration package conflict with rpm-cron.

(In reply to comment #18)
> To sum it up. We will stick with cron_log_t context and update permissions to
> 644.

By default, the permissions will be 644, so why are they explicitly set? To knowingly override a more secure default umask that the administrator has specifically configured (in order to reduce the amount of information disclosed to all users)?

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
No documentation needed (documentation should be provided via selinux-policy errata on bug 820535)

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.

http://rhn.redhat.com/errata/RHBA-2012-0909.html