5

Reading this recent research paper on how to use information from /proc/interrupts to attack a system, I was wondering whether there is a particular reason why /proc/interrupts is world-readable. Indeed my Arch Linux machine reports

ls -al /proc/interrupts 
-r--r--r-- 1 root root 0 24. Mai 18:03 /proc/interrupts

Does it hurt to make this file readable for root only?

  • Any particular reason to hide it? Security by obscurity is not security. (I'd assume reading the table from memory using code is not a privileged operation anyways.) – billc.cn May 24 '16 at 17:24
  • Well, that is an odd argument, having research show that this information may be used to attack the system. There are pobably also good reasons that /etc/shadow is not world-readable. – Florian May 24 '16 at 18:17
5

It's world-readable now because it was made world-readable when it was created twenty years ago or so. I haven't researched the history (which probably exists only in Linus Torvalds's head anyway) but it's likely that this file is world-readable because there's no obvious reason to make it so. After all, it doesn't contain any confidential information: just some system configuration and some performance statistics...

The subtlety is that while taking one snapshot of /proc/interrupts is harmless, reading it in a tight loop isn't, because that reveals the rate of keystrokes which in turn leaks quite a bit of information about what was typed.

Side channels didn't get much attention outside of cryptography until a few years ago, when app markets became mainstream and everybody and their grandmother runs code downloaded from shady sites such as the App Store or Google Play. So I'm not surprised that such issues (which already existed on typical multiuser systems in the 1990s) are now getting publicized and studied in more depth in the context of smartphones.

Changing the statu quo isn't an easy decision since the Linux kernel has some very strong backward compatibility leanings. The information in /proc/interrupts is useful when debugging application or driver code or system performance problems.

Restricting access to /proc/interrupts wouldn't block the side channel completely, just one relatively convenient way to observe it. It's also possible to observe keystroke timing by observing when the process that reads them is scheduled, and what an attacker needs to do that is more or less what the top program needs (and displays, if you just increase the default 1Hz refresh rate).

4

It seems that the issue has been reported back in 2011. In addition, a patch proposed to make /proc/interrupts readable by root only.

By reading the thread, it seems that they consider the distributions should change the permission of /proc/interrupts if they wanted to. An issue was raised about the fact that it can be cumbersome to force everyone mounting procfs to change the permissions. The author of the patch also asked why this is not the default, but no answer was provided (as far as I know).

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.