Mounting /sys directories with nosuid option

I’m trying to mount some file systems in the /sys directory with the nosuid option. Upon executing the command:

mount -o remount,nosuid /sys/kernel/security
remount nosuid /sys/kernel/security

/etc/mtab will show that they have been applied, but upon restart of the machine, the nosuid option is removed.

Soooo, the question is why are they being removed? Can /sys files carry the nosuid option? Is there another way to do this?

Welcome to the forums !!!

AFAIK the sysfs is mounted from fstab, but I don’t understand what you’re trying to achieve. Never touched the sysfs. Anyway, they are removed because mounting during boot is done in /etc/fstab

IMHO a mount is not a thing that lasts over a reboot.

The reasoning is that we’re starting to use OpenSUSE at a gov’t location, but we have to STIG (Harden) it. We’re using a SRR script to find the vulnerabilities and this is one that has me stuck. In basics, I have to mount the following files systems with nosuid.

debugfs on /sys/kernel/debut type debugfs (rw)
/dev/sda7 on /home type ext3 (rw,acl,user_xattr)
securityfs on /sys/kernel/security type securityfs (rw)
fusectl on /sys/fs/fuse/connections type fusectl (rw)

But I’ve yet to have any success in getting them to retain after reboot.

You should use the same options in fstab that you use to mount manually. Do a ‘man fstab’ to see how that works. Your fstab already contains entries for sysfs, debugfs and fusefs, the manpages will tell you how to use the mount options.

I think your SRR script just doesn’t understand that /sys is a synthetic filesystem, not a real one, which is a window into kernel status. So it doesn’t take the nosuid option.

Synthetic file system - Wikipedia, the free encyclopedia

Like ken_yap I think this is pure nonsense. When there aren’t any executables inside this file system (and I don’t think there will be one), the suid/guid bite are of no use. So why bother?

One should always take these scripts with suspicion. They are often written by people who do not quite understand what a document about hardening means to do. They only read littarally something like: filesystems should be moounted … And they often even do not know to much about Unix/Linux either.

The problem is how to explain to your boss that the script he proudly presented to you is bogus.

I agree, a large portion of Information Assurance is nonsense, or at minimum, overkill. The bad part is that we have to meet the DOD standards, so nonsense or not, we have to fix it. The only ones that refuse to take the NOSUID option are the /sys files, but this is ok, we can document that.

Thanks for all of the help.