[PATCH] proc: restrict access to /proc/interrupts

[PATCH] proc: restrict access to /proc/interrupts

[Vasiliy Kulikov]

/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

Cc: <stable@kernel.org>
Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
---
 fs/proc/interrupts.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/proc/interrupts.c b/fs/proc/interrupts.c
index 05029c0..2fe87a1 100644
--- a/fs/proc/interrupts.c
+++ b/fs/proc/interrupts.c
@@ -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

Re: [PATCH] proc: restrict access to /proc/interrupts

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1492 bytes --]

On Mon, 07 Nov 2011 21:45:22 +0400, Vasiliy Kulikov said:
> /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

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...


[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: [PATCH] proc: restrict access to /proc/interrupts

[Vasiliy Kulikov]

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

On Mon, Nov 07, 2011 at 13:06 -0500, Valdis.Kletnieks@vt.edu wrote:
> On Mon, 07 Nov 2011 21:45:22 +0400, Vasiliy Kulikov said:
> > /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
> 
> 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.

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


> This whack-a-mole  "turn off permissions on generally useful files because
> there's an exposure" really has to stop.

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.


> 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.

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.


> 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

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?


> in a more fine-grained manner than "chmod it to 0").

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

[kernel-hardening] Re: [PATCH] proc: restrict access to /proc/interrupts

[Vasiliy Kulikov]

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

On Mon, Nov 07, 2011 at 13:06 -0500, Valdis.Kletnieks@vt.edu wrote:
> On Mon, 07 Nov 2011 21:45:22 +0400, Vasiliy Kulikov said:
> > /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
> 
> 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.

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


> This whack-a-mole  "turn off permissions on generally useful files because
> there's an exposure" really has to stop.

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.


> 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.

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.


> 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

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?


> in a more fine-grained manner than "chmod it to 0").

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

Re: [PATCH] proc: restrict access to /proc/interrupts

[H. Peter Anvin]

On 11/07/2011 11:01 AM, Vasiliy Kulikov wrote:
> 
> 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.
> 

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

[kernel-hardening] Re: [PATCH] proc: restrict access to /proc/interrupts

[H. Peter Anvin]

On 11/07/2011 11:01 AM, Vasiliy Kulikov wrote:
> 
> 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.
> 

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

Re: [kernel-hardening] Re: [PATCH] proc: restrict access to /proc/interrupts

[Vasiliy Kulikov]

On Mon, Nov 07, 2011 at 11:18 -0800, H. Peter Anvin wrote:
> On 11/07/2011 11:01 AM, Vasiliy Kulikov wrote:
> > 
> > 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.
> > 
> 
> I would like to propose that we add a mount option to procfs, and
> possibly sysfs, called, say, admingrp.

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.


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

Agreed.


Thanks,

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

Re: [kernel-hardening] Re: [PATCH] proc: restrict access to /proc/interrupts

[Eric Paris]

On Mon, Nov 7, 2011 at 2:29 PM, Vasiliy Kulikov <segoon@openwall.com> wrote:
> On Mon, Nov 07, 2011 at 11:18 -0800, H. Peter Anvin wrote:

> 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.

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.....

Re: [kernel-hardening] Re: [PATCH] proc: restrict access to /proc/interrupts

[H. Peter Anvin]

On 11/07/2011 11:48 AM, Eric Paris wrote:
> On Mon, Nov 7, 2011 at 2:29 PM, Vasiliy Kulikov <segoon@openwall.com> wrote:
>> On Mon, Nov 07, 2011 at 11:18 -0800, H. Peter Anvin wrote:
> 
>> 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.
> 
> 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

Re: [kernel-hardening] Re: [PATCH] proc: restrict access to /proc/interrupts

[Vasiliy Kulikov]

On Mon, Nov 07, 2011 at 14:48 -0500, Eric Paris wrote:
> On Mon, Nov 7, 2011 at 2:29 PM, Vasiliy Kulikov <segoon@openwall.com> wrote:
> > On Mon, Nov 07, 2011 at 11:18 -0800, H. Peter Anvin wrote:
> 
> > 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.
> 
> 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.

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

Re: [PATCH] proc: restrict access to /proc/interrupts

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 972 bytes --]

On Mon, 07 Nov 2011 11:18:32 PST, "H. Peter Anvin" said:

> 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.

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?

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

Amen, brother. ;)

[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

[kernel-hardening] Re: [PATCH] proc: restrict access to /proc/interrupts

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 972 bytes --]

On Mon, 07 Nov 2011 11:18:32 PST, "H. Peter Anvin" said:

> 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.

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?

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

Amen, brother. ;)

[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: [kernel-hardening] Re: [PATCH] proc: restrict access to /proc/interrupts

[Vasiliy Kulikov]

On Mon, Nov 07, 2011 at 11:50 -0800, H. Peter Anvin wrote:
> On 11/07/2011 11:48 AM, Eric Paris wrote:
> > On Mon, Nov 7, 2011 at 2:29 PM, Vasiliy Kulikov <segoon@openwall.com> wrote:
> >> On Mon, Nov 07, 2011 at 11:18 -0800, H. Peter Anvin wrote:
> > 
> >> 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.
> > 
> > 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.

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

Re: [PATCH] proc: restrict access to /proc/interrupts

[Vasiliy Kulikov]

On Mon, Nov 07, 2011 at 15:10 -0500, Valdis.Kletnieks@vt.edu wrote:
> On Mon, 07 Nov 2011 11:18:32 PST, "H. Peter Anvin" said:
> 
> > 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.
> 
> 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?

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

[kernel-hardening] Re: [PATCH] proc: restrict access to /proc/interrupts

[Vasiliy Kulikov]

On Mon, Nov 07, 2011 at 15:10 -0500, Valdis.Kletnieks@vt.edu wrote:
> On Mon, 07 Nov 2011 11:18:32 PST, "H. Peter Anvin" said:
> 
> > 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.
> 
> 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?

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

Re: [kernel-hardening] Re: [PATCH] proc: restrict access to /proc/interrupts

[H. Peter Anvin]

On 11/07/2011 12:11 PM, Vasiliy Kulikov wrote:
> 
> 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.
> 

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

Re: [kernel-hardening] Re: [PATCH] proc: restrict access to /proc/interrupts

[Linus Torvalds]

On Mon, Nov 7, 2011 at 12:47 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>
> 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.

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

Re: [kernel-hardening] Re: [PATCH] proc: restrict access to /proc/interrupts

[H. Peter Anvin]

On 11/07/2011 01:23 PM, Linus Torvalds wrote:
> On Mon, Nov 7, 2011 at 12:47 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>>
>> 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.
> 
> 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.
> 

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

Re: [kernel-hardening] Re: [PATCH] proc: restrict access to /proc/interrupts

[Linus Torvalds]

On Mon, Nov 7, 2011 at 1:35 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>
> 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.

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

Re: [kernel-hardening] Re: [PATCH] proc: restrict access to /proc/interrupts

[Alan Cox]

> 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.

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.

> Faking it with posix acl's is what the /dev/audio stuff tends to do.

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.

> 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.

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

Re: [kernel-hardening] Re: [PATCH] proc: restrict access to /proc/interrupts

[Greg KH]

On Mon, Nov 07, 2011 at 11:21:32PM +0000, Alan Cox wrote:
> > 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.
> 
> 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.

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

Re: [kernel-hardening] Re: [PATCH] proc: restrict access to /proc/interrupts

[Theodore Tso]

On Nov 7, 2011, at 6:27 PM, Greg KH wrote:
> 
> So, what do we really need revoke() for these days?

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.

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

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
 

Re: [kernel-hardening] Re: [PATCH] proc: restrict access to /proc/interrupts

[Alan Cox]

> 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.

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

Alan

Re: [kernel-hardening] Re: [PATCH] proc: restrict access to /proc/interrupts

[Greg KH]

On Mon, Nov 07, 2011 at 06:40:13PM -0500, Theodore Tso wrote:
> 
> On Nov 7, 2011, at 6:27 PM, Greg KH wrote:
> > 
> > So, what do we really need revoke() for these days?
> 
> 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.

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

> > But that's getting away from the original topic here, sorry…
> 
> 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.

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

Re: [kernel-hardening] Re: [PATCH] proc: restrict access to /proc/interrupts

[Vasiliy Kulikov]

On Mon, Nov 07, 2011 at 15:27 -0800, Greg KH wrote:
> So, what do we really need revoke() for these days?

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

Re: [kernel-hardening] Re: [PATCH] proc: restrict access to /proc/interrupts

[Alan Cox]

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

So the distro can chmod it 0400

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

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.

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

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

Re: [kernel-hardening] Re: [PATCH] proc: restrict access to /proc/interrupts

[John Stoffel]

>>>>> "Linus" == Linus Torvalds <torvalds@linux-foundation.org> writes:

Linus> On Mon, Nov 7, 2011 at 12:47 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> 
>> 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.

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?  

Re: [kernel-hardening] Re: [PATCH] proc: restrict access to /proc/interrupts

[Vasiliy Kulikov]

On Tue, Nov 08, 2011 at 13:23 +0000, Alan Cox wrote:
> > /proc/{interrupts,stat} are 0444, which may be used by local attacker to
> > learn statistical information about user's keystrokes, including the
> > passwords.
> 
> So the distro can chmod it 0400

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.


> > /dev/pts/* and /dev/tty* leak the same timing information in inode's
> > atime and mtime.
> 
> 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.

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


> The atime/mtime behaviour is however required ABI and used by
> applications so can't simply go away.

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.


> > Do we want to restrict permissions of interrupts/stat and remove atime
> > and mtime from ttys and relax these permissions when revoke() is introduced?
> 
> revoke makes no difference I can see to either of these, they appear to
> be a completely unrelated discussion.

/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

Re: [kernel-hardening] Re: [PATCH] proc: restrict access to /proc/interrupts

[Ted Ts'o]

On Mon, Nov 07, 2011 at 03:45:46PM -0800, Greg KH wrote:
> > 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.
> 
> So you want revoke() on a block device to do what?  The same thing as
> disconnecting it from the hardware level?

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

Re: [kernel-hardening] Re: [PATCH] proc: restrict access to /proc/interrupts

[Greg KH]

On Tue, Nov 08, 2011 at 03:07:35PM -0500, Ted Ts'o wrote:
> On Mon, Nov 07, 2011 at 03:45:46PM -0800, Greg KH wrote:
> > > 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.
> > 
> > So you want revoke() on a block device to do what?  The same thing as
> > disconnecting it from the hardware level?
> 
> 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.

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.

> 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.  

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