openscap icon indicating copy to clipboard operation
openscap copied to clipboard

Openscap does not respect bind mount partition permission values

Open ddanielr opened this issue 9 years ago • 3 comments

When implementing a bind mount for /tmp, the openscap checks fail for the noexec,nosuid,and nodev permission settings for /tmp mount.

While the permissions are set correctly it appears that the openscap check is getting it's information from /proc/mounts which does not accurately display partition permissions for bind mounts.

I purpose moving the source of the inquery from /proc/mounts to either mount, /etc/fstab, or /etc/mtab

Different outputs from /etc/fstab, /etc/mtab, and mount /etc/fstab UUID=f857466b-a4a3-4346-84a5-8859f5f6f4cb / ext4 defaults 1 1 tmpfs /dev/shm tmpfs defaults,nosuid,noexec,nodev 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 /tmp /var/tmp none rw,nodev,noexec,nosuid,bind 0 0 /home /home none rw,nodev,noexec,nosuid,bind 0 0 /tmp /tmp none defaults,nodev,noexec,nosuid,bind 0 0 /var /var none rw,nodev,noexec,nosuid,bind 0 0 /var/log /var/log none rw,nodev,noexec,nosuid,bind 0 0 /var/log/audit /var/log/audit none rw,nodev,noexec,nosuid,bind 0 0 /etc/mtab /dev/vda1 / ext4 rw 0 0 proc /proc proc rw 0 0 sysfs /sys sysfs rw 0 0 devpts /dev/pts devpts rw,gid=5,mode=620 0 0 tmpfs /dev/shm tmpfs rw,noexec,nosuid,nodev,rootcontext="system_u:object_r:tmpfs_t:s0" 0 0 /tmp /var/tmp none rw,noexec,nosuid,nodev,bind 0 0 /home /home none rw,noexec,nosuid,nodev,bind 0 0 /tmp /tmp none rw,noexec,nosuid,nodev,bind 0 0 /var /var none rw,noexec,nosuid,nodev,bind 0 0 /var/log /var/log none rw,noexec,nosuid,nodev,bind 0 0 /var/log/audit /var/log/audit none rw,noexec,nosuid,nodev,bind 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0 mount command /dev/vda1 on / type ext4 (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) tmpfs on /dev/shm type tmpfs (rw,noexec,nosuid,nodev,rootcontext="system_u:object_r:tmpfs_t:s0") /tmp on /var/tmp type none (rw,noexec,nosuid,nodev,bind) /home on /home type none (rw,noexec,nosuid,nodev,bind) /tmp on /tmp type none (rw,noexec,nosuid,nodev,bind) /var on /var type none (rw,noexec,nosuid,nodev,bind) /var/log on /var/log type none (rw,noexec,nosuid,nodev,bind) /var/log/audit on /var/log/audit type none (rw,noexec,nosuid,nodev,bind) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) /proc/mounts rootfs / rootfs rw 0 0 proc /proc proc rw,relatime 0 0 sysfs /sys sysfs rw,seclabel,relatime 0 0 devtmpfs /dev devtmpfs rw,seclabel,relatime,size=1953052k,nr_inodes=488263,mode=755 0 0 devpts /dev/pts devpts rw,seclabel,relatime,gid=5,mode=620,ptmxmode=000 0 0 tmpfs /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0 /dev/vda1 / ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0 none /selinux selinuxfs rw,relatime 0 0 devtmpfs /dev devtmpfs rw,seclabel,relatime,size=1953052k,nr_inodes=488263,mode=755 0 0 /dev/vda1 /var/tmp ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0 /dev/vda1 /home ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0 **/dev/vda1 /tmp ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0** /dev/vda1 /var ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0 /dev/vda1 /var/log ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0 /dev/vda1 /var/log/audit ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0

ddanielr avatar Feb 08 '16 22:02 ddanielr

Note:

ll /etc/mtab
lrwxrwxrwx. 1 root root 19 jan 21 20:00 /etc/mtab -> ../proc/self/mounts

Currently there is no way how to correctly distinguish bind mounts, since kernel does not provide this information to user space. See similar issues in coreutils [1, 2].

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1001092#c15 [2] https://bugzilla.redhat.com/show_bug.cgi?id=920806#c18

EDIT: Note also that /proc/mounts is symlink to /proc/self/mounts

fridex avatar May 20 '16 08:05 fridex

So if I understand it well, due to this we are not able to fix this in OpenSCAP right now.

jan-cerny avatar Jun 27 '16 07:06 jan-cerny

The https://bugzilla.redhat.com/show_bug.cgi?id=1001092#c15 is fixed now. Do we have to do anything else on the scanner side?

evgenyz avatar Aug 25 '20 08:08 evgenyz