I want to hide /dev files on Linux because some files can be dumped and used for reverse engineering/attack purposes.

My primary goal is to avoid users able to see those files from a shell: lurking on internet I've seen udev can be a solution but I want to avoid its use.

Any suggestion?

  • Don't users need things in the /dev directory to access hardware? Like hda1
    – schroeder
    Oct 26 '18 at 19:16
  • What files can be "dumped and used for reverse engineering/attack purposes"? Do you have an example?
    – schroeder
    Oct 26 '18 at 19:16
  • Perhaps this might help? unix.stackexchange.com/questions/18239/…
    – schroeder
    Oct 26 '18 at 19:18
  • Not all users need to access to all present hardware. Flash devices (mtdblock*) can be used to dump data and /dev/random or /dev/urandom to DoS attacks. The last link is a good description of dev directory but no info about its "hardening".
    – Drew Ber
    Oct 26 '18 at 19:30
  • blocking /dev/urandom might block the user from a variety of necessary things
    – schroeder
    Oct 26 '18 at 19:35

I would suggest you look at whether or not you can actually do anything with those files on the system you're looking at securing as a regular user. Most likely, you will find out that most of the really important ones (storage devices for example) already cannot be accessed by regular users, because that's the standard configuration on a vast majority of UNIX systems, even as far back as 4.3BSD and SVR4. If you're being truly realistic, disallowing non-root access to these device files is probably sufficient for security (if the attacker has root access, device files don't matter because they can probably get code running in kernel space easily, which doesn't need device files to poke at hardware). If the system in question is configured to use SELinux or another LSM, you can also leverage that (if the default configuration doesn't already) to further limit access.

Even if you hide or block paths under /dev though, that doesn't really prevent people from creating new device nodes elsewhere with the appropriate major and minor device numbers and arbitrary permissions. You can't easily stop people from creating such files, but you can make them essentially useless by mounting everything except /dev with the nodev mount option, which disables special handling of device nodes on the mounted filesystem. Properly doing this requires that your root filesystem be separate from /dev (which should be either some automatic virtual filesystem provided by the kernel (such as devtmpfs) or a tmpfs instance populated by a device manager).

Beyond that, a lot of the really nasty ones (/dev/mem, /dev/port, /dev/kmem, and /dev/msr, as well as /dev/hpet) can be completely disabled at compile time. This doesn't just keep them from appearing in /dev, it means that you literally can't ever have working instances of these device nodes on the system. Most Linux distributions explicitly disable /dev/kmem these days because nothing uses it, and a lot of them also disable /dev/mem and /dev/port because they are largely only used by legacy software. /dev/msr on the other hand is usually built as a loadable module (and thus can be explicitly blacklisted without rebuilding the kernel) because there are actual practical uses for it that don't involve attacking the system (for example, debugging CPU power-management issues).

Also, as a sight aside, don't block /dev/null or /dev/urandom, you'll probably break your system if you do, and neither one is a really an attack vector.



The idea of representing most aspects of a computer operating system and its hardware as files is both central and critical to the design of Unix (plan 9 takes this even further). If it does not implement these then it's not Unix/POSIX. While Linux took this in a slightly different direction with devfs (which was succeeded by udev) it is still a defining characteristic of the os.


because some files can be dumped and used for reverse engineering/attack purposes

...and access to these are controlled by permissions. If you think that's not adequate protection then I suggest you research how often file permissions have been bypassed on such systems (nb I'm not talking about setuid programs - these are executables given explicit privileges to behave differently - and are a relatively common source of exploits).

You wouldn't gain anything by doing this but you would break the os completely.

A better way to start learning about Linux security and how to harden your system would be to look at some of the hardening guides available, e.g. from CIS or SANS

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.