proc: restrict access to /proc/interrupts

/proc/interrupts contains the number of emitted interrupts, which should not be world readable. The information about keyboard interrupts number may be used to learn the precise number of characters in users' passwords by simply watching the changes of number of emitted interrupts during the life of gksu-like programs.

The PoC is publicly available at:

http://www.openwall.com/lists/oss-security/2011/11/07/9

---
 fs/proc/interrupts.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

index 05029c0..2fe87a1 100644
@@ -47,7 +47,7 @@ static const struct file_operations proc_interrupts_operations = {
 
 static int __init proc_interrupts_init(void)
 {
-	proc_create("interrupts", 0, NULL, &proc_interrupts_operations);
+	proc_create("interrupts", S_IRUSR, NULL, &proc_interrupts_operations);
 	return 0;
 }
 module_init(proc_interrupts_init);

1.7.0.4

This doesn't close the hole entirely. You can still figure it out by watching the files in /dev/pts/ and /dev/tty* for changes in last-modify time.

This whack-a-mole "turn off permissions on generally useful files because there's an exposure" really has to stop. On probably the vast majority of Linux systems, it's an embedded or a laptop/desktop, and if you have a malicious user running code on it already, the fact they can find out how many characters are in the password is the *least* of your problems.

This sort of thing needs to be done as part of an overall security model (in other words, something like Smack or SELinux should be moderating the accesses in a more fine-grained manner than "chmod it to 0").

And if you're worried about them knowing the length of the password, you probably should be using appropriate PAM configurations to enforce a minimum length/complexity high enough that even if they know the password is 23 characters long, it doesn't do them any real good...

(cc'ed LSM@, kernel-hardening and Linus)

Good point, thanks. Also I've missed /proc/stat - it contains the same interrupt counters.

I dissagree with you. If not pay an attention to historical procfs flaws, they will never be fixed. If we know some subsystem leaks much private information because of some historical incidents, we still must fix it. If some subsystem has flaws here and there, it probably needs a redesign or at least more accurate audit.

Sure, but 2 notes here.

First, the number of characters is indeed not really harmful, but the precise timings can provide additional information, which can be matched against the statistical information about how much time it takes to move fingers between different keys. This can be used to gain a valuable probabilistic information about the password characters, and running the attack several times can result in the _precise_ passwords learning. The details of the attack can be found here:

https://db.usenix.org/event/sec09/tech/full_papers/zhang.pdf

Second, ability to protect local users from each other is a core feature of multiuser systems. One user must not get private keys of other users, must not be able to listen ttys of other users, etc. The issue with side channel attacks is much more complex (e.g. it's really hard to design a scheduler to remove all possible indirect infoleaks via schedule delays), but the issue in question is not so tricky, quite the opposite - relaxed permissions.

Huh? Do you claim that current Linux doesn't implement the multiuser system _by design_? Do you say every distro that doesn't use any LSMs (like Debian) is actually not a true multiuser system? Or am I missing your point?

What's wrong with old good DAC? You can create a group "sysinfo", do "chown sysinfo /proc/interrupts", and add the permitted users to the group. If you need to give different access levels to different interrupts, you need another /proc/interrupts design, it does nothing with DAC vs. LSM.

Thanks,

Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments

I would like to propose that we add a mount option to procfs, and possibly sysfs, called, say, admingrp. These kinds of files then get restricted to the admingrp (defaulting to gid 0 if no admingrp is provided). Historically on Unix there has been a group of people (usually "adm", but sometimes "log") who are allowed to read (but not write) the log files, which also contains potentially sensitive information.

The current Linux trend seems to be do instead force those users to become root constantly, which is *not* helping the situation.

-hpa

Similar proposals:

(procfs for /proc/$PID/* permissions, sorry about different threads)
https://lkml.org/lkml/2011/6/15/172
https://lkml.org/lkml/2011/6/15/174
https://lkml.org/lkml/2011/6/15/173
https://lkml.org/lkml/2011/6/15/177
https://lkml.org/lkml/2011/6/15/175
https://lkml.org/lkml/2011/6/15/176

(change uid/gid for newly created sysfs objects)
https://lkml.org/lkml/2011/5/18/272

As to procfs, I see no real need of adding mode/group mount option for global procfs files (/proc/interrupts, /proc/stat, etc.) - it can be done by distro specific init scripts (chown+chmod). I don't mind against such an option for the convenience, though.

Agreed.

Thanks,

Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments

While possible, the chmod+chown 'solutions' just aren't as simple as you pretend. Every time one creates a chroot environment and mounts /proc it has be manually fixed there as well. Same thing with a container. Sure if /proc were something that was only ever mounted one time on a box it wouldn't be so bad, but that's not the case.....

Yes, for a filesystem that dynamically creates nodes, a static script just doesn't work well. Control options do, like we have for devpts for example.

-hpa

My statement was about static files - /proc/{interrupts,meminfo,stat,cpuinfo}. They don't change during the system life. /proc/$PID/* files are indeed dymanic and the first link in my quoted email was about addition of such mount options.

Thanks,

Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments

You didn't really get my point. There are global nodes which are dynamic, and more importantly the *set* changes across the system life.
A global policy option is a lot easier to deal with for the vast
majority of users who don't need fine grain control.

-hpa

I want *one* global policy that the kernel would actually know about:
is the user physically at the machine right now.

Sadly, I don't think the kernel has any good way to figure that out automatically.

Because quite frankly, a lot of the /proc files should be "root or desktop user". If you control the hardware, you should damn well be able to see the interrupt counts in order to do bug reports etc without having to 'sudo' or similar.

I realize that pam & co could give us this info, or we could just add a new capability flag, but I think this is something where the kernel really could just do the RightThing(tm) automatically, and screw the crazy login managers, odd policies (I really don't believe that adding magic selinux rules actually improves security all that much, because it's too painful and too hard to know for any normal user).

The person in front of the hardware really *is* fundamentally special.

Right now all the distros do magic things with the audio device because they know the person in front of the machine is special. But all those things are ad-hoc per device, and never cover things like random /proc files etc.

Linus

I was going to say "let's just have the login manager add a group to the desktop user's permission set" but then I realized that this would be really bad because of setgid files.

Which exposes a real problem with chgrp and setgid files overall.

The way setgid works effectively means that any user can become a member of any group that they have at any time been a member of, simply by "stashing" a copy of the group as a setgid file:

cp /bin/sh my-saved-group
chgrp mygroup my-saved-group
chmod g+s my-saved-group

This is rather messy, because gids are otherwise a very nice capability mechanism.

-hpa

No, the problem is more fundamental, and this is simply not something you should try to solve with traditional unix permissions.

Why? Because the problem really isn't about opening the file. The problem is about any access: once you've opened the file, you *still* must not be able to read the data from it if you have logged out and somebody else has logged in. Think opening the microphone (which you *should* be able to do) and just keeping it open until the next user logs in.

Or do the same with /proc/interrupts.

Your "oops, you can get your group permissions back with a setgrp binary" example case is just a trivial case of the much bigger
picture: access has to be actively *revoked*.

Sure, you can still do it in user space, but it gets really hacky really quickly. You need to do some magic random permission logic, *and* you need to add revoke support for every single file that ends up being affected.

It's just a broken model.

So I really think it would be much better to just have a per-user flag that says "this user has access to the physical machine", and that flag gets tested not only on open but on reads etc of the appropriate /proc files. It really is a kind of "temporary admin privileges", where "admin" is much weaker than root, but does mean that you have access to whatever directly attached devices (sound/video/keyboard/whatever), and that you can examine machine state (ie a lot of the "sensitive" /proc stuff, like slabinfo and interrupts and /proc/status etc).

Trying to fake it with groups is wrong. It's much *better* to fake it with POSIX ACL's (which don't have the setgrp issue you mention), but that still ends up being problematic wrt revoke etc.

Faking it with posix acl's is what the /dev/audio stuff tends to do. It's better than nothing, but it really isn't wonderful - because it's really not just about audio. And revoke doesn't work universally.

Practically speaking, I suspect we are going to be at the mercy of distros getting things like this right, with these kinds of user-level hacks. But I think it's sad.

Linus

We need minimal revocation stuff. This hasn't changed in years. You can mostly work around it with SELinux but the underlying problem is that you need a small controlled subset of revokable devices and objects and a meaningful way to revoke them.

The latter is hard to do with a simple noddy model because there are multi-user systems with multiple audio devices, multiple displays and the like where the mapping is not a simple 'this list of objects is console' but needs user space to do the work.

The audio stuff mostly uses daemons to manage it. A bigger problem is file system mounts. If you've got an old handle on /dev/cdrom you can pass it down a socket to a background irritant that just does an eject every five minutes. Students were doing this in SunOS 4 and I'm sure still find it funny today.

BSD invented revoke but never implemented it universally. It turns out that this isn't a big problem. Right now we basically only have revoke for tty devices but we don't need it for that much more. Revoke on disk files and the like has simply never happened because its not a matter of revoke being universal so much as universal revoke being universally pointless.

Alan

I looked into implementing revoke() a while ago, and looked at how BSD did it. They really only implemented it for a very narrow range of devices (tty only I think), which is not what we really want.

I thought people wanted it for all char and block devices, if this isn't so, then it might be easier to implement than I thought.

So, what do we really need revoke() for these days?

But that's getting away from the original topic here, sorry...

greg k-h

As I mentioned at the kernel summit, I'd like revoke along with a formal notification from block devices that get ejected to the file system layer, and the file system should be able to call a VFS library function which revokes all open file descriptor on the ejected block device. It would result in much cleaner handling at the file system level when a USB storage device gets pulled.

Yup. But if revoke has come up, I'd like to remind folks that there are good uses of it besides just tty devices that receive hangup events. Having the modem connection disappear and the USB device disappear isn't all that different from a conceptual point of view.

-- Ted

And for USB tty which actually treat them the same and do exactly this 8)

Alan

So you want revoke() on a block device to do what? The same thing as disconnecting it from the hardware level?

Oh, I forgot that this came up while we were drinking at the LinuxCon Japan conference this year and we figured out that you could just use the 'unbind' and 'bind' files in sysfs to disconnect and reconnect the device from the driver from userspace which would simulate a revoke() call on pretty much any type of char device we have today.

Sure, it's crude, and yes, it's the result of a lot of whisky, but even now, it still seems like a nice hack if you really want and need this from userspace :)

thanks,

greg k-h

No, what I meant is that a disconnect at the hardware level should lead to notification to the file system via a call to struct super operations function. And then the file system can use that callback (call it super->s_ops->device_ejected) to call revoke on all of the open files on the file system.

If we were to implement a revoke(2) system call (as opposed to just VFS functionality callable from kernel code), it should probably do what revoke(2) does on other Unix systems:

The revoke() system call invalidates all current open file descriptors in the system for the file named by path. Subsequent operations on any such descriptors fail, with the exceptions that a read() from a character device file which has been revoked returns a count of zero (end of file), and a close() system call will succeed. If the file is a special file for a device which is open, the device close function is called as if all open references to the file had been closed.

Access to a file may be revoked only by its owner or the super user. The revoke() system call is currently supported only for block and character special device files. It is normally used to prepare a terminal device for a new login session, preventing any access by a previous user of the terminal.

The revoke functionality I was talking about is a way to disconnect a file descriptor from the mounted file system, since when the device that backed it has disappeared, the file system should disappear as well. What should be left are file descriptors that return an error when read or written, and which are administratively managed by the VFS layer, with all of the file system's refcounts appropriate decremented, such that if it were loaded as a module, the fs module could be safely unloaded.

- Ted

What other Unix systems actually implement revoke() in this manner? I looked at the BSDs a while ago, and they only do revoke() on a tty character device node.

So are there other examples of someone actually implementing this in a manner that works and is usable? If so, pointers would be greatly appreciated, as well as the userspace side that takes advantage of such a system call.

That can be implemented today without the need for the userspace revoke() call to be added, right? Just propagate around the device disconnect message that the disk controller driver already knows about.

thanks,

greg k-h

revoke() of /proc/$PID/* descriptors would also solve the issue of keeping them across exec() of setuid/setgid binaries:

https://lkml.org/lkml/2011/2/7/368

Currently there are explicit calls to lock_trace()/unlock_trace(), which
(1) pollute the code and (2) significantly slow it down.

So, where are we now? We tend to agree revoke() is needed, but what to do before it is implemented? In the context of this thread I see the following problems:

/proc/{interrupts,stat} are 0444, which may be used by local attacker to learn statistical information about user's keystrokes, including the passwords.

/dev/pts/* and /dev/tty* leak the same timing information in inode's atime and mtime.

Do we want to restrict permissions of interrupts/stat and remove atime and mtime from ttys and relax these permissions when revoke() is introduced?

Thanks,

Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments

So the distro can chmod it 0400

That one is trickier. I don't think it is a real leak because the last update timing info is in seconds granularity so is pretty useless for that. The atime/mtime behaviour is however required ABI and used by applications so can't simply go away.

revoke makes no difference I can see to either of these, they appear to be a completely unrelated discussion.

Sorry, but I miss the logic. Why do you think it's better to leave the known unsecure defaults and rely on distros fix the permissions? Why not restrict it to the secure defaults and leave the decision who to trust (i.e. all users, only current user, nobody) to distros? The decision has to be done either way, but in the 1st case the harm of lack of chmod is much more significant.

No, I see the precise counters:

S=''; while :; do N=stat -L /dev/pts/3 | sed -n 5p; [ "$N" != "$S" ] && echo "$N"; S=$N; done

Access: 2011-11-08 21:25:41.219869215 +0400
Access: 2011-11-08 21:25:41.249869259 +0400
Access: 2011-11-08 21:25:41.289869313 +0400
Access: 2011-11-08 21:25:41.329869368 +0400
Access: 2011-11-08 21:25:41.369869433 +0400
Access: 2011-11-08 21:25:41.399869479 +0400
Access: 2011-11-08 21:25:41.439869532 +0400
Access: 2011-11-08 21:25:41.479869591 +0400
Access: 2011-11-08 21:25:41.519869655 +0400
Access: 2011-11-08 21:25:41.549869697 +0400

Sure, we cannot remove atime/mtime from struct stat for ttys, but we can leave these fields zero (or equal to any const sane date) if we know that the tty owner and the process belong to different security domains (euid check or smth. like may_ptrace()). The quesion here is: are there users of checking time counters of _foreign_ ttys? If no, leaving these counters blank will not break anything.

/proc/$PID/* will certainly benefit from revoke() - all ptrace check could be made at open time, not on every read()/write() invocation.

/proc/* will benefit from revoke() if the permission logic is implemented as Linus wants to see it - as dynamically re-chown'ed files, which invalidate old fds on re'chown.

tty issue is indeed unrelated, sorry for the confusion.

Thanks,

Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments

Linus> I want *one* global policy that the kernel would actually know about:
Linus> is the user physically at the machine right now.

Linus> Sadly, I don't think the kernel has any good way to figure that out Linus> automatically.

Linus> Because quite frankly, a lot of the /proc files should be "root or Linus> desktop user". If you control the hardware, you should damn well be Linus> able to see the interrupt counts in order to do bug reports etc Linus> without having to 'sudo' or similar.

Linus> I realize that pam & co could give us this info, or we could just add Linus> a new capability flag, but I think this is something where the kernel Linus> really could just do the RightThing(tm) automatically, and screw the Linus> crazy login managers, odd policies (I really don't believe that adding Linus> magic selinux rules actually improves security all that much, because Linus> it's too painful and too hard to know for any normal user).

Linus> The person in front of the hardware really *is* fundamentally special.

Except when they're my kids and I don't want them to shutdown or
suspend the box when they login/logout. For example, I work on my
desktop at night, and after school, they just login to the same box as their own account, do their thing, etc. Then at night after they're in bed, I use the same machine. But something they've rebooted it, or whatever. A pain.

Linus> Right now all the distros do magic things with the audio device Linus> because they know the person in front of the machine is Linus> special. But all those things are ad-hoc per device, and never Linus> cover things like random /proc files etc.

It's really hard to know who's sitting there. And what about multi-seat setups?

I admit I don't fully realize all possible containers' uses, but doesn't procfs is mounted inside of containers for only restricted full-featured Linux distros usermods with the whole init and init scripts set? I didn't see any consistent usages of procfs for other things, do they exist?

Creating separate namespaces is very useful for additional daemon restrictions like vsftpd does it, but procfs inside of such namespace is obviously denied by design ;)

And as procfs is a one instance per pid namespace, it has the same permissions in all mount points, so I see no problem with chroot (however, I find chroot not very useful with procfs inside).

Thanks,

Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments

Probably should be a two part - mount with 'gid=NNN', and then a perm=027 or whatever, to be treated similar to a umask. So 027 would allow root to do anything, would disable write for the gid= group, and turn it off completely for others. Less paranoid sites could mount it with perm=002.

Does that cover most of the use cases?

Amen, brother. ;)

At the time of Linux 2.0-2.4 in Owl patch there was a plain on/off configure option - 022 / 066 umask. Currently procfs restriction is implemented in Grsecurity with the same all-or-nothing approach. Brad Spengler told me that there were no user complains about the lack of
flexibility :-) So, I agree that we don't need anything more complex.

Thanks,

Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments