Hi,
Making /proc/kallsyms readable only for root makes it harder
for attackers to write generic kernel exploits by removing
one source of knowledge where things are in the kernel.
This is the second submit, discussion happened on this on first submit
and mostly concerned that this is just one hole of the sieve ... but
one of the bigger ones.
Changing the permissions of at least System.map and vmlinux is
also required to fix the same set, but a packaging issue.
Target of this starter patch and follow ups is removing any kind of
kernel space address information leak from the kernel.
Ciao, Marcus
Signed-off-by: Marcus Meissner <[email protected]>
Acked-by: Tejun Heo <[email protected]>
Acked-by: Eugene Teo <[email protected]>
Reviewed-by: Jesper Juhl <[email protected]>
---
kernel/kallsyms.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 6f6d091..a8db257 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -546,7 +546,7 @@ static const struct file_operations kallsyms_operations = {
static int __init kallsyms_init(void)
{
- proc_create("kallsyms", 0444, NULL, &kallsyms_operations);
+ proc_create("kallsyms", 0400, NULL, &kallsyms_operations);
return 0;
}
device_initcall(kallsyms_init);
--
1.7.1
On Tue, Nov 16, 2010 at 11:46:03AM +0100, Marcus Meissner wrote:
> Target of this starter patch and follow ups is removing any kind of
> kernel space address information leak from the kernel.
>
Er. Should probably hit /proc/modules while you're at it.
--Kyle
On Tue, Nov 16, 2010 at 05:46, Marcus Meissner <[email protected]> wrote:
> Making /proc/kallsyms readable only for root makes it harder
> for attackers to write generic kernel exploits by removing
> one source of knowledge where things are in the kernel.
>
> This is the second submit, discussion happened on this on first submit
> and mostly concerned that this is just one hole of the sieve ... but
> one of the bigger ones.
>
> Changing the permissions of at least System.map and vmlinux is
> also required to fix the same set, but a packaging issue.
>
> Target of this starter patch and follow ups is removing any kind of
> kernel space address information leak from the kernel.
[...snip...]
> - proc_create("kallsyms", 0444, NULL, &kallsyms_operations);
> + proc_create("kallsyms", 0400, NULL, &kallsyms_operations);
Erm... this still seems to be missing a couple of really major
criticisms from the last review:
(1) For 99%+ of all the computers out there you can get a 90%+
accurate guess for what kernel is running by looking at the version of
libc installed on the system. All you have to do for those computers
is download a bunch of distro kernels and look at the libc packages
and build a table of "libc6-SOMEVERSION => 0xADDRESS", etc. Because
of how all the vendors backport and track versions, "SOMEVERSION"
usually includes something wonderfully helpful like "el5" or "squeeze"
or whatever. This does *nothing* for those users, and it's not clear
that it ever *could*.
(2) Most of the arguments about introducing "uncertainty" into the
hacking process are specious as well. If a kernel bug is truly a
"workable" vulnerability then 99%+ of the attempts to exploit it would
be completely automated virii and computer worms that don't really
care what happens if they fail to compromise the system. Take a look
at the vast collection of sample code we have in the form of Windows
virii/trojans/worms/malware/etc; care to guess what portion of those
programs authors would shed a tear if their exploit horribly crashed
or generated vast amounts of audit spam for 70% of the computers it
executed on?
(2) By just flat out changing the permissions on this file you are
breaking all sorts of existing debugging and analysis tools (which
currently operate just fine as non-root). If you make the argument
that those people "can just write a boot script to 'chmod' the file",
well, you *too* can write a boot script to just chmod the file.
Furthermore, if you're truly locking down a system that hard, there
are lots of other boot scripts you will be modifying already anyways.
(3) If you are really interested in locking down a system to this
degree then you should also be using an appropriate LSM, which is
already a much better place to hook these sorts of specific checks.
In fact, with roughly a 5-line SELinux policy change I could already
close this so-called "security hole" with no kernel changes
whatsoever.
Cheers,
Kyle Moffett
Whoops... I apparently can't count to 3... (at least not correctly anyways) :-D.
On Wed, Nov 17, 2010 at 00:40, Kyle Moffett <[email protected]> wrote:
> (1) For 99%+ of all the computers out there you can get a 90%+
[...]
> (2) Most of the arguments about introducing "uncertainty" into the
[...]
> (2) By just flat out changing the permissions on this file you are
[...]
> (3) If you are really interested in locking down a system to this
Cheers,
Kyle Moffett
On Tue, Nov 16, 2010 at 9:40 PM, Kyle Moffett <[email protected]> wrote:
>
> ?(1) For 99%+ of all the computers out there you can
I think that misses the point.
Security is never about absolutes. Anybody who believes in absolute
security is a moron.
True security is about "piling up the inconveniences on the attack".
Several layers. Sure, it's easy to attack a system that is a
monoculture. But immediately when you start saying "you can always
figure out the particular version" and you're talking about tens (or
hundreds) of versions, suddenly you really _are_ more secure. Because
suddenly it's one more pain.
And no, that "one more pain" is not going to be the thing that stops
attacks. But add a number of "one more pains" together, and it gets
increasingly unlikely that you will have a widespread and successful
attack.
So I do think that it's worth closing these "small" holes. Anything
that makes it more work to attack really _is_ improving things.
And being able to just immediately see the addresses is just very
convenient if you have an attack that needs kernel addresses. Much
better that we not make these things visible by default.
And yes, people can look at the vmlinux files. That's outside our
control. And maybe distros will want to close that hole, and maybe
they won't, but at least they don't have the excuse that "well, it's
not even worth it, because the kernel exports that information in
/proc/kallsyms already".
Linus
On Tue, Nov 16, 2010 at 09:58:44PM -0800, Linus Torvalds wrote:
> So I do think that it's worth closing these "small" holes. Anything
> that makes it more work to attack really _is_ improving things.
We must keep in mind that anything which requires more work as root
for common administration opens new holes. I don't think it's the
case for kallsyms, but I mean we should not try to lock too hard,
otherwise everyone will have a sudoers entry to do his work, and
that's even worse than current situation.
Willy
Putting aside the kallsyms patch (which is a tiny part of a fuller solution), i'd
like to reply to this particular point:
* Kyle Moffett <[email protected]> wrote:
> (2) Most of the arguments about introducing "uncertainty" into the
> hacking process are specious as well. [...]
It is only specious if you ignore the arguments i made in the previous
discussion. One argument i made was:
Future trends are also clear: eventually, as more and more of our lives
are lived on the network, home boxes are becoming more and more valuable.
So i think concentrating on the psychology of the skilled attacker would
not be unwise. YMMV.
> [...] If a kernel bug is truly a
> "workable" vulnerability then 99%+ of the attempts to exploit it would
> be completely automated virii and computer worms that don't really
> care what happens if they fail to compromise the system. Take a look
> at the vast collection of sample code we have in the form of Windows
> virii/trojans/worms/malware/etc; care to guess what portion of those
> programs authors would shed a tear if their exploit horribly crashed
> or generated vast amounts of audit spam for 70% of the computers it
> executed on?
( You'd be a fool to think that even windows malware authors do not care
whether they crash the target box. You do not get a botnet of 10 million PCs if
you crash 99% of them. There is an analogous concept for this in biology: if a
biological virus is _too_ deadly, it will never become a pandemic - because it has
no time/chance to spread, they are 'detected' and 'defended against'. Virii like
Ebola never spread widely, because they kill all their hosts. )
More importantly, look forward and take a look at the really intelligent attacks,
which are used against high-value targets with good defenses. Those real examples
give us a glimpse into future techniques, even if you do not accept my arguments
that come to a similar conclusion. Those attacks are all about avoiding detection.
Thanks,
Ingo
* Kyle McMartin <[email protected]> wrote:
> On Tue, Nov 16, 2010 at 11:46:03AM +0100, Marcus Meissner wrote:
> > Target of this starter patch and follow ups is removing any kind of
> > kernel space address information leak from the kernel.
> >
>
> Er. Should probably hit /proc/modules while you're at it.
Agreed. A few other kernel address things that should be hidden are:
1) /proc/<PID>/stack
Gives out kernel addresses and is a partial /proc/kallsyms table in essence. This
got introduced recently. Useful to attackers.
Then there's a handful of physical address leaks - those are less useful but useful
in some situations:
2) /proc/mtrr
Gives some idea about the physical layout of the machine and can give information
about the location of certain physical devices as well. Limited but nonzero utility
to attackers.
3) /proc/asound/cards
Can gives out the physical address of a device. Limited but nonzero utility to
attackers.
4) /sys/devices/*/*/resources
Shows physical addresses. Limited but nonzero utility to attackers.
Plus there's some really limited fractional pieces of information - again, of
nonzero utility to attackers:
5) /proc/net/ptype
Shows the sizes of a few kernel functions in networking code. Very limited but
nonzero utility to attackers.
6) /sys/kernel/slab/*/ctor
Shows the sizes of a few kernel functions. Very limited but nonzero utility to
attackers.
7) /sys/module/*/sections/*
For example:
/sys/module/sunrpc/sections/__bug_table
/sys/module/sunrpc/sections/__ex_table
/sys/module/sunrpc/sections/__ksymtab
/sys/module/sunrpc/sections/__ksymtab_gpl
/sys/module/sunrpc/sections/__ksymtab_strings
/sys/module/sunrpc/sections/__mcount_loc
/sys/module/sunrpc/sections/__param
Potentially useful to attackers.
There's probably a few more i missed.
Ingo
On Tue, Nov 16, 2010 at 11:46:03AM +0100, Marcus Meissner wrote:
> Hi,
>
> Making /proc/kallsyms readable only for root makes it harder
> for attackers to write generic kernel exploits by removing
> one source of knowledge where things are in the kernel.
>
> This is the second submit, discussion happened on this on first submit
> and mostly concerned that this is just one hole of the sieve ... but
> one of the bigger ones.
>
> Changing the permissions of at least System.map and vmlinux is
> also required to fix the same set, but a packaging issue.
>
> Target of this starter patch and follow ups is removing any kind of
> kernel space address information leak from the kernel.
>
> Ciao, Marcus
>
> Signed-off-by: Marcus Meissner <[email protected]>
> Acked-by: Tejun Heo <[email protected]>
> Acked-by: Eugene Teo <[email protected]>
> Reviewed-by: Jesper Juhl <[email protected]>
On Wednesday, I updated my branch to commit 460781b from linus' tree,
and my box would not boot. klogd segfaulted, which stalled the whole
system.
At first I thought it actually hung the box, but it continued booting
after 5 minutes, and I was able to log in. It dropped back to the text
console instead of the graphical bootup display for that period of time.
dmesg surprisingly still works. I've bisected the problem down to this
commit (commit 59365d136d205cc20fe666ca7f89b1c5001b0d5a in
linus/master).
.config and dmesg are attached. The box is running klogd 1.5.5ubuntu3
(from Jaunty). Yes, I know that's old. I read the bit in the commit
about changing the permissions of kallsyms after boot, but if I can't
boot that doesn't help. Perhaps this can be made a configuration
option?
Sarah Sharp
On Fri, Nov 19, 2010 at 11:19 AM, Sarah Sharp
<[email protected]> wrote:
>
> .config and dmesg are attached. ?The box is running klogd 1.5.5ubuntu3
> (from Jaunty). ?Yes, I know that's old. ?I read the bit in the commit
> about changing the permissions of kallsyms after boot, but if I can't
> boot that doesn't help. ?Perhaps this can be made a configuration
> option?
It's not worth a config option.
If it actually breaks user-space, I think we should just revert it.
It's kind of sad to default to the world-visible thing, but as I
mentioned in the commit, this is something where a sysadmin or distro
can trivially just fix it at boot-time too, with just a
chmod og-r /proc/kallsyms
in your bootup scripts.
And if somebody has taken control of the machine _before_ the bootup
scripts get to run, you have bigger problems than a /proc/kallsyms
file.
So I guess I'll revert it.
Thanks for testing and bisecting.
Linus
On Fri, 19 Nov 2010, Linus Torvalds wrote:
> On Fri, Nov 19, 2010 at 11:19 AM, Sarah Sharp
> <[email protected]> wrote:
>>
>> .config and dmesg are attached. ?The box is running klogd 1.5.5ubuntu3
>> (from Jaunty). ?Yes, I know that's old. ?I read the bit in the commit
>> about changing the permissions of kallsyms after boot, but if I can't
>> boot that doesn't help. ?Perhaps this can be made a configuration
>> option?
>
> It's not worth a config option.
>
> If it actually breaks user-space, I think we should just revert it.
how far back do we need to maintain compatibility with userspace?
Is this something that we can revisit in a few years and lock it down
then?
David Lang
> It's kind of sad to default to the world-visible thing, but as I
> mentioned in the commit, this is something where a sysadmin or distro
> can trivially just fix it at boot-time too, with just a
>
> chmod og-r /proc/kallsyms
>
> in your bootup scripts.
>
> And if somebody has taken control of the machine _before_ the bootup
> scripts get to run, you have bigger problems than a /proc/kallsyms
> file.
>
> So I guess I'll revert it.
>
> Thanks for testing and bisecting.
>
> Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Fri, Nov 19, 2010 at 11:58 AM, <[email protected]> wrote:
>
> how far back do we need to maintain compatibility with userspace?
>
> Is this something that we can revisit in a few years and lock it down then?
The rule is basically "we never break user space".
But the "out" to that rule is that "if nobody notices, it's not
broken". In a few years? Who knows?
So breaking user space is a bit like trees falling in the forest. If
there's nobody around to see it, did it really break?
Linus
On Fri, Nov 19, 2010 at 12:04:47PM -0800, Linus Torvalds wrote:
> On Fri, Nov 19, 2010 at 11:58 AM, <[email protected]> wrote:
> >
> > how far back do we need to maintain compatibility with userspace?
> >
> > Is this something that we can revisit in a few years and lock it down then?
>
> The rule is basically "we never break user space".
>
> But the "out" to that rule is that "if nobody notices, it's not
> broken". In a few years? Who knows?
>
> So breaking user space is a bit like trees falling in the forest. If
> there's nobody around to see it, did it really break?
FWIW, I appreciate a lot that non-breaking rule. I have some testing
machines which boot from PXE or USB on a file-system with some old
tools and libc, that are both 2.4 and 2.6 compatible. Everything works
like a charm, the only point of care was to have both module-init-tools
and modutils (obviously) but even that integrates smoothly.
I know quite a lot of people who never replace user-space but only
kernels on their systems, so this non-breaking rule is much welcome !
Willy
On Fri, 19 Nov 2010, Willy Tarreau wrote:
> On Fri, Nov 19, 2010 at 12:04:47PM -0800, Linus Torvalds wrote:
>> On Fri, Nov 19, 2010 at 11:58 AM, <[email protected]> wrote:
>>>
>>> how far back do we need to maintain compatibility with userspace?
>>>
>>> Is this something that we can revisit in a few years and lock it down then?
>>
>> The rule is basically "we never break user space".
>>
>> But the "out" to that rule is that "if nobody notices, it's not
>> broken". In a few years? Who knows?
>>
>> So breaking user space is a bit like trees falling in the forest. If
>> there's nobody around to see it, did it really break?
>
> FWIW, I appreciate a lot that non-breaking rule. I have some testing
> machines which boot from PXE or USB on a file-system with some old
> tools and libc, that are both 2.4 and 2.6 compatible. Everything works
> like a charm, the only point of care was to have both module-init-tools
> and modutils (obviously) but even that integrates smoothly.
>
> I know quite a lot of people who never replace user-space but only
> kernels on their systems, so this non-breaking rule is much welcome !
Please don't get me wrong, as a general rule I like it a lot (I almost
never run the stock kernel from a distro and I upgrade kernels _far_ more
frequently than anything else).
However, like every other general rule, there are reasons to make
exceptions.
In this case we are changing the default to make it more secure, I think
that's worth something.
Yes, distros can all add the chmod command to their startup to get similar
behavior. But by the same token, if we change the default, someone running
an old distro can add a chmod command into their bootup to allow their old
software to still work. In the case that has been identified, the problem
is that syslog is unable to get the kernel messages. this can be
important, but in my opinion it's a long way from being a fatal flaw. I've
already seen this sort of problem happen in the wild without this change.
I was running a development version of rsyslog and on a ubuntu system a
year or so ago (before they switched to rsyslog), I had a situation where
firing up rsyslog would generate a lot of messages about being unable to
read the kernel logs (I don't remember the exact message, it wasn't this
kallsyms file, it was something else)
my full-time job is in security for banks, so I'm a bit more sensitive to
the security issues than most people (but tend to agree with Linus about
the security industry and security circus), but I see this as something
that is useful enough to put in (with a compile-time flag if the
compatibility is that critical for this function). I expect that there are
going to be a few more security patches coming down the road that would be
good to put under the same or similar flag (either because they may break
some old software like eliminating /proc/kmem, or because they add a
slight amount of overhead like the nx/read-only patches). As a result I
think something similar to the 'embedded' option would be appropriate,
have these new features on by default, but have some way that people who
need to disable them can do so.
David Lang
> On Fri, Nov 19, 2010 at 11:19 AM, Sarah Sharp
> <[email protected]> wrote:
> >
> > .config and dmesg are attached. The box is running klogd 1.5.5ubuntu3
> > (from Jaunty). Yes, I know that's old. I read the bit in the commit
> > about changing the permissions of kallsyms after boot, but if I can't
> > boot that doesn't help. Perhaps this can be made a configuration
> > option?
>
> It's not worth a config option.
>
> If it actually breaks user-space, I think we should just revert it.
User space klogd is what's broken in this case:
ksyms = fopen(KSYMS, "r");
if ( ksyms == NULL )
{
if ( errno == ENOENT )
Syslog(LOG_INFO, "No module symbols loaded - "
"kernel modules not enabled.\n");
else
Syslog(LOG_ERR, "Error loading kernel symbols " \
"- %s\n", strerror(errno));
fclose(ksyms);
return(0);
}
The fclose(NULL) is a bug, as I don't think the standards require
that to be handled gracefully.
> It's kind of sad to default to the world-visible thing,
klogd also gets symbols from System.map, so /proc/kallsyms access
is not a strict requirement.
I haven't checked to see if klogd can work without a symbol source
at all, but I'll wager it can.
Regards,
Andy
On Fri, Nov 19, 2010 at 1:12 PM, Andy Walls <[email protected]> wrote:
>>
>> If it actually breaks user-space, I think we should just revert it.
>
> User space klogd is what's broken in this case:
Sure. I'm not surprised. I didn't really expect the /proc/kallsyms
mode change to trigger anything like what Sarah reported, and
user-space just being buggy because the error case had never even been
tested is quite understandable.
But the thing is, it doesn't even matter.
The rule is not "we don't break non-buggy user space" or "we don't
break reasonable user-space". The rule is simply "we don't break
user-space".
Even if the breakage is totally incidental, that doesn't help the
_user_. It's still breakage.
We still have magic scheduler debug options to run children before
parents after fork, simply because that used to _hide_ a race
condition in some older "bash" versions (or maybe it was the other way
around, whatever).
The thing is, bugs happen. And if they never had test coverage, we
can't blame people for them. Saying "tough luck, we changed it, and
you did something wrong" may be manly, but it's also unacceptable. The
developer may fix his bug, but there's still users out there.
Now, there _are_ exceptions. There are always exceptions. Intelligent
people don't run things off a script, and it's obviously always to
some degree a judgment call. The breakage has to be balanced against
the upsides. If the kernel behavior change is due to some fundamental
security issue or a major redesign that we _had_ to do to make
progress, and the user-level breakage is reasonably well-contained,
we'll just say "sorry, we had to do it".
In this case, the upside just wasn't big enough to accept _any_
breakage, especially since people and distributions can just do the
"chmod" themselves if they want to. There was a lot of discussion
whether the patch should even go in in the first place. So this time,
the "let's just revert it" was a very easy decision for me.
Linus
On Fri, Nov 19, 2010 at 03:22:00PM -0800, Linus Torvalds wrote:
> In this case, the upside just wasn't big enough to accept _any_
> breakage, especially since people and distributions can just do the
> "chmod" themselves if they want to. There was a lot of discussion
> whether the patch should even go in in the first place. So this time,
> the "let's just revert it" was a very easy decision for me.
The downside is that /proc can be remounted multiple times for different
containers, etc. Having to patch everything that mounts /proc to do the
chmod seems much more painful that fixing a simple userspace bug in an old
klog daemon.
(For example, rsyslogd handles this fine since it's root to open it, and
even if it fails, it doesn't do the broken fclose().)
-Kees
--
Kees Cook
Ubuntu Security Team
On Thu, Nov 18, 2010 at 08:48:04AM +0100, Ingo Molnar wrote:
> Agreed. A few other kernel address things that should be hidden are:
> [snip]
For reference, here's what GRKERNSEC_HIDESYM looks like in grsecurity.
It's quite a sledgehammer, but it does help to point out at least the
minimum number of things that need fixing.
And, more directly related to this thread, kallsyms hiding is implemented
in s_show instead of via DAC:
@@ -464,6 +467,11 @@ static int s_show(struct seq_file *m, vo
{
struct kallsym_iter *iter = m->private;
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+ if (current_uid())
+ return 0;
+#endif
+
/* Some debugging symbols have no name. Ignore them. */
if (!iter->name[0])
return 0;
Here's the rest, manually extracted, untested, etc...
---
arch/powerpc/kernel/process.c | 10 +++++-----
arch/sparc/kernel/process_32.c | 8 ++++----
arch/sparc/kernel/process_64.c | 8 ++++----
arch/sparc/kernel/traps_32.c | 2 +-
arch/sparc/kernel/traps_64.c | 22 +++++++++++-----------
arch/sparc/kernel/unaligned_64.c | 2 +-
arch/sparc/mm/fault_64.c | 2 +-
arch/x86/kernel/dumpstack.c | 2 +-
drivers/message/fusion/mptbase.c | 5 +++++
fs/proc/array.c | 6 ++++++
fs/proc/base.c | 12 ++++++------
fs/proc/kcore.c | 3 +++
include/linux/kallsyms.h | 11 ++++++++++-
kernel/configs.c | 6 ++++++
kernel/kallsyms.c | 10 +++++++++-
kernel/module.c | 5 +++++
kernel/panic.c | 5 +++--
kernel/time/timer_list.c | 8 ++++++++
kernel/time/timer_stats.c | 4 ++++
lib/Kconfig.debug | 1 +
lib/vsprintf.c | 16 ++++++++++++++--
mm/kmemleak.c | 2 +-
mm/slub.c | 2 +-
net/atm/proc.c | 5 +++++
net/ipv4/inet_diag.c | 21 +++++++++++++++++++++
net/ipv4/tcp_ipv4.c | 19 +++++++++++++++++--
net/ipv4/udp.c | 7 ++++++-
net/ipv6/raw.c | 8 +++++++-
net/ipv6/tcp_ipv6.c | 23 ++++++++++++++++++++---
net/ipv6/udp.c | 7 ++++++-
net/key/af_key.c | 4 ++++
net/netlink/af_netlink.c | 8 ++++++++
net/packet/af_packet.c | 4 ++++
net/phonet/socket.c | 7 ++++++-
net/sctp/proc.c | 14 ++++++++++++--
net/unix/af_unix.c | 4 ++++
36 files changed, 230 insertions(+), 53 deletions(-)
diff -urNp linux-2.6.36/drivers/message/fusion/mptbase.c linux-2.6.36/drivers/message/fusion/mptbase.c
--- linux-2.6.36/drivers/message/fusion/mptbase.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/drivers/message/fusion/mptbase.c 2010-11-06 19:06:37.000000000 -0400
@@ -6681,8 +6681,13 @@ static int mpt_iocinfo_proc_show(struct
seq_printf(m, " MaxChainDepth = 0x%02x frames\n", ioc->facts.MaxChainDepth);
seq_printf(m, " MinBlockSize = 0x%02x bytes\n", 4*ioc->facts.BlockSize);
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+ seq_printf(m, " RequestFrames @ 0x%p (Dma @ 0x%p)\n", NULL, NULL);
+#else
seq_printf(m, " RequestFrames @ 0x%p (Dma @ 0x%p)\n",
(void *)ioc->req_frames, (void *)(ulong)ioc->req_frames_dma);
+#endif
+
/*
* Rounding UP to nearest 4-kB boundary here...
*/
diff -urNp linux-2.6.36/fs/proc/array.c linux-2.6.36/fs/proc/array.c
--- linux-2.6.36/fs/proc/array.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/fs/proc/array.c 2010-11-06 18:58:50.000000000 -0400
@@ -452,6 +452,12 @@ static int do_task_stat(struct seq_file
gtime = task->gtime;
}
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+ wchan = 0;
+ eip =0;
+ esp =0;
+#endif
+
/* scale priority and nice values from timeslices to -20..20 */
/* to make it look like a "normal" Unix priority/nice value */
priority = task_prio(task);
diff -urNp linux-2.6.36/fs/proc/base.c linux-2.6.36/fs/proc/base.c
--- linux-2.6.36/fs/proc/base.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/fs/proc/base.c 2010-11-06 18:58:50.000000000 -0400
@@ -296,7 +296,7 @@ static int proc_pid_auxv(struct task_str
}
-#ifdef CONFIG_KALLSYMS
+#if defined(CONFIG_KALLSYMS) && !defined(CONFIG_GRKERNSEC_HIDESYM)
/*
* Provides a wchan file via kallsyms in a proper one-value-per-file format.
* Returns the resolved symbol. If that fails, simply return the address.
@@ -318,7 +318,7 @@ static int proc_pid_wchan(struct task_st
}
#endif /* CONFIG_KALLSYMS */
-#ifdef CONFIG_STACKTRACE
+#if defined(CONFIG_STACKTRACE) && !defined(CONFIG_GRKERNSEC_HIDESYM)
#define MAX_STACK_TRACE_DEPTH 64
@@ -2705,10 +2705,10 @@ static const struct pid_entry tgid_base_
#ifdef CONFIG_SECURITY
DIR("attr", S_IRUGO|S_IXUGO, proc_attr_dir_inode_operations, proc_attr_dir_operations),
#endif
-#ifdef CONFIG_KALLSYMS
+#if defined(CONFIG_KALLSYMS) && !defined(CONFIG_GRKERNSEC_HIDESYM)
INF("wchan", S_IRUGO, proc_pid_wchan),
#endif
-#ifdef CONFIG_STACKTRACE
+#if defined(CONFIG_STACKTRACE) && !defined(CONFIG_GRKERNSEC_HIDESYM)
ONE("stack", S_IRUSR, proc_pid_stack),
#endif
#ifdef CONFIG_SCHEDSTATS
@@ -3040,10 +3040,10 @@ static const struct pid_entry tid_base_s
#ifdef CONFIG_SECURITY
DIR("attr", S_IRUGO|S_IXUGO, proc_attr_dir_inode_operations, proc_attr_dir_operations),
#endif
-#ifdef CONFIG_KALLSYMS
+#if defined(CONFIG_KALLSYMS) && !defined(CONFIG_GRKERNSEC_HIDESYM)
INF("wchan", S_IRUGO, proc_pid_wchan),
#endif
-#ifdef CONFIG_STACKTRACE
+#if defined(CONFIG_STACKTRACE) && !defined(CONFIG_GRKERNSEC_HIDESYM)
ONE("stack", S_IRUSR, proc_pid_stack),
#endif
#ifdef CONFIG_SCHEDSTATS
diff -urNp linux-2.6.36/fs/proc/kcore.c linux-2.6.36/fs/proc/kcore.c
--- linux-2.6.36/fs/proc/kcore.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/fs/proc/kcore.c 2010-11-06 18:58:50.000000000 -0400
@@ -542,6 +542,9 @@ read_kcore(struct file *file, char __use
static int open_kcore(struct inode *inode, struct file *filp)
{
+#if defined(CONFIG_GRKERNSEC_HIDESYM)
+ return -EPERM;
+#endif
if (!capable(CAP_SYS_RAWIO))
return -EPERM;
if (kcore_need_update)
diff -urNp linux-2.6.36/include/linux/kallsyms.h linux-2.6.36/include/linux/kallsyms.h
--- linux-2.6.36/include/linux/kallsyms.h 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/include/linux/kallsyms.h 2010-11-15 17:10:35.000000000 -0500
@@ -15,7 +15,8 @@
struct module;
-#ifdef CONFIG_KALLSYMS
+#if !defined(__INCLUDED_BY_HIDESYM) || !defined(CONFIG_KALLSYMS)
+#if defined(CONFIG_KALLSYMS) && !defined(CONFIG_GRKERNSEC_HIDESYM)
/* Lookup the address for a symbol. Returns 0 if not found. */
unsigned long kallsyms_lookup_name(const char *name);
@@ -92,6 +93,14 @@ static inline int lookup_symbol_attrs(un
/* Stupid that this does nothing, but I didn't create this mess. */
#define __print_symbol(fmt, addr)
#endif /*CONFIG_KALLSYMS*/
+#else /* when included by kallsyms.c or vsnprintf.c, with HIDESYM enabled */
+extern void __print_symbol(const char *fmt, unsigned long address);
+extern int sprint_symbol(char *buffer, unsigned long address);
+const char *kallsyms_lookup(unsigned long addr,
+ unsigned long *symbolsize,
+ unsigned long *offset,
+ char **modname, char *namebuf);
+#endif
/* This macro allows us to keep printk typechecking */
static void __check_printsym_format(const char *fmt, ...)
diff -urNp linux-2.6.36/kernel/configs.c linux-2.6.36/kernel/configs.c
--- linux-2.6.36/kernel/configs.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/kernel/configs.c 2010-11-06 18:58:50.000000000 -0400
@@ -73,8 +73,14 @@ static int __init ikconfig_init(void)
struct proc_dir_entry *entry;
/* create the current config file */
+#if defined(CONFIG_GRKERNSEC_HIDESYM)
+ entry = proc_create("config.gz", S_IFREG | S_IRUSR, NULL,
+ &ikconfig_file_ops);
+#else
entry = proc_create("config.gz", S_IFREG | S_IRUGO, NULL,
&ikconfig_file_ops);
+#endif
+
if (!entry)
return -ENOMEM;
diff -urNp linux-2.6.36/kernel/kallsyms.c linux-2.6.36/kernel/kallsyms.c
--- linux-2.6.36/kernel/kallsyms.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/kernel/kallsyms.c 2010-11-06 18:58:50.000000000 -0400
@@ -11,6 +11,9 @@
* Changed the compression method from stem compression to "table lookup"
* compression (see scripts/kallsyms.c for a more complete description)
*/
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+#define __INCLUDED_BY_HIDESYM 1
+#endif
#include <linux/kallsyms.h>
#include <linux/module.h>
#include <linux/init.h>
@@ -464,6 +467,11 @@ static int s_show(struct seq_file *m, vo
{
struct kallsym_iter *iter = m->private;
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+ if (current_uid())
+ return 0;
+#endif
+
/* Some debugging symbols have no name. Ignore them. */
if (!iter->name[0])
return 0;
@@ -504,7 +512,7 @@ static int kallsyms_open(struct inode *i
struct kallsym_iter *iter;
int ret;
- iter = kmalloc(sizeof(*iter), GFP_KERNEL);
+ iter = kzalloc(sizeof(*iter), GFP_KERNEL);
if (!iter)
return -ENOMEM;
reset_iter(iter, 0);
diff -urNp linux-2.6.36/kernel/module.c linux-2.6.36/kernel/module.c
--- linux-2.6.36/kernel/module.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/kernel/module.c 2010-11-06 18:58:50.000000000 -0400
@@ -3075,6 +3075,11 @@ static const struct file_operations proc
static int __init proc_modules_init(void)
{
+#ifndef CONFIG_GRKERNSEC_HIDESYM
+ proc_create("modules", S_IRUSR, NULL, &proc_modules_operations);
+#else
+ proc_create("modules", S_IRUSR, NULL, &proc_modules_operations);
+#endif
return 0;
}
module_init(proc_modules_init);
diff -urNp linux-2.6.36/kernel/time/timer_list.c linux-2.6.36/kernel/time/timer_list.c
--- linux-2.6.36/kernel/time/timer_list.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/kernel/time/timer_list.c 2010-11-06 18:58:50.000000000 -0400
@@ -38,12 +38,16 @@ DECLARE_PER_CPU(struct hrtimer_cpu_base,
static void print_name_offset(struct seq_file *m, void *sym)
{
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+ SEQ_printf(m, "<%p>", NULL);
+#else
char symname[KSYM_NAME_LEN];
if (lookup_symbol_name((unsigned long)sym, symname) < 0)
SEQ_printf(m, "<%p>", sym);
else
SEQ_printf(m, "%s", symname);
+#endif
}
static void
@@ -112,7 +116,11 @@ next_one:
static void
print_base(struct seq_file *m, struct hrtimer_clock_base *base, u64 now)
{
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+ SEQ_printf(m, " .base: %p\n", NULL);
+#else
SEQ_printf(m, " .base: %p\n", base);
+#endif
SEQ_printf(m, " .index: %d\n",
base->index);
SEQ_printf(m, " .resolution: %Lu nsecs\n",
diff -urNp linux-2.6.36/kernel/time/timer_stats.c linux-2.6.36/kernel/time/timer_stats.c
--- linux-2.6.36/kernel/time/timer_stats.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/kernel/time/timer_stats.c 2010-11-06 18:58:50.000000000 -0400
@@ -269,12 +269,16 @@ void timer_stats_update_stats(void *time
static void print_name_offset(struct seq_file *m, unsigned long addr)
{
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+ seq_printf(m, "<%p>", NULL);
+#else
char symname[KSYM_NAME_LEN];
if (lookup_symbol_name(addr, symname) < 0)
seq_printf(m, "<%p>", (void *)addr);
else
seq_printf(m, "%s", symname);
+#endif
}
static int tstats_show(struct seq_file *m, void *v)
diff -urNp linux-2.6.36/lib/Kconfig.debug linux-2.6.36/lib/Kconfig.debug
--- linux-2.6.36/lib/Kconfig.debug 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/lib/Kconfig.debug 2010-11-06 19:03:24.000000000 -0400
@@ -998,6 +998,7 @@ config LATENCYTOP
depends on DEBUG_KERNEL
depends on STACKTRACE_SUPPORT
depends on PROC_FS
+ depends on !GRKERNSEC_HIDESYM
select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE
select KALLSYMS
select KALLSYMS_ALL
diff -urNp linux-2.6.36/lib/vsprintf.c linux-2.6.36/lib/vsprintf.c
--- linux-2.6.36/lib/vsprintf.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/lib/vsprintf.c 2010-11-13 16:31:35.000000000 -0500
@@ -16,6 +16,9 @@
* - scnprintf and vscnprintf
*/
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+#define __INCLUDED_BY_HIDESYM 1
+#endif
#include <stdarg.h>
#include <linux/module.h>
#include <linux/types.h>
@@ -574,7 +577,7 @@ char *symbol_string(char *buf, char *end
unsigned long value = (unsigned long) ptr;
#ifdef CONFIG_KALLSYMS
char sym[KSYM_SYMBOL_LEN];
- if (ext != 'f' && ext != 's')
+ if (ext != 'f' && ext != 's' && ext != 'a')
sprint_symbol(sym, value);
else
kallsyms_lookup(value, NULL, NULL, NULL, sym);
@@ -947,6 +950,8 @@ char *uuid_string(char *buf, char *end,
* - 'f' For simple symbolic function names without offset
* - 'S' For symbolic direct pointers with offset
* - 's' For symbolic direct pointers without offset
+ * - 'A' For symbolic direct pointers with offset approved for use with GRKERNSEC_HIDESYM
+ * - 'a' For symbolic direct pointers without offset approved for use with GRKERNSEC_HIDESYM
* - 'R' For decoded struct resource, e.g., [mem 0x0-0x1f 64bit pref]
* - 'r' For raw struct resource, e.g., [mem 0x0-0x1f flags 0x201]
* - 'M' For a 6-byte MAC address, it prints the address in the
@@ -989,7 +994,7 @@ char *pointer(const char *fmt, char *buf
struct printf_spec spec)
{
if (!ptr)
- return string(buf, end, "(null)", spec);
+ return string(buf, end, "(nil)", spec);
switch (*fmt) {
case 'F':
@@ -998,6 +1003,13 @@ char *pointer(const char *fmt, char *buf
/* Fallthrough */
case 'S':
case 's':
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+ break;
+#else
+ return symbol_string(buf, end, ptr, spec, *fmt);
+#endif
+ case 'A':
+ case 'a':
return symbol_string(buf, end, ptr, spec, *fmt);
case 'R':
case 'r':
diff -urNp linux-2.6.36/net/atm/proc.c linux-2.6.36/net/atm/proc.c
--- linux-2.6.36/net/atm/proc.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/net/atm/proc.c 2010-11-06 18:58:50.000000000 -0400
@@ -190,7 +190,12 @@ static void vcc_info(struct seq_file *se
{
struct sock *sk = sk_atm(vcc);
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+ seq_printf(seq, "%p ", NULL);
+#else
seq_printf(seq, "%p ", vcc);
+#endif
+
if (!vcc->dev)
seq_printf(seq, "Unassigned ");
else
diff -urNp linux-2.6.36/net/ipv4/inet_diag.c linux-2.6.36/net/ipv4/inet_diag.c
--- linux-2.6.36/net/ipv4/inet_diag.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/net/ipv4/inet_diag.c 2010-11-13 16:33:13.000000000 -0500
@@ -114,8 +114,14 @@ static int inet_csk_diag_fill(struct soc
r->idiag_retrans = 0;
r->id.idiag_if = sk->sk_bound_dev_if;
+
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+ r->id.idiag_cookie[0] = 0;
+ r->id.idiag_cookie[1] = 0;
+#else
r->id.idiag_cookie[0] = (u32)(unsigned long)sk;
r->id.idiag_cookie[1] = (u32)(((unsigned long)sk >> 31) >> 1);
+#endif
r->id.idiag_sport = inet->inet_sport;
r->id.idiag_dport = inet->inet_dport;
@@ -201,8 +207,15 @@ static int inet_twsk_diag_fill(struct in
r->idiag_family = tw->tw_family;
r->idiag_retrans = 0;
r->id.idiag_if = tw->tw_bound_dev_if;
+
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+ r->id.idiag_cookie[0] = 0;
+ r->id.idiag_cookie[1] = 0;
+#else
r->id.idiag_cookie[0] = (u32)(unsigned long)tw;
r->id.idiag_cookie[1] = (u32)(((unsigned long)tw >> 31) >> 1);
+#endif
+
r->id.idiag_sport = tw->tw_sport;
r->id.idiag_dport = tw->tw_dport;
r->id.idiag_src[0] = tw->tw_rcv_saddr;
@@ -285,12 +298,14 @@ static int inet_diag_get_exact(struct sk
if (sk == NULL)
goto unlock;
+#ifndef CONFIG_GRKERNSEC_HIDESYM
err = -ESTALE;
if ((req->id.idiag_cookie[0] != INET_DIAG_NOCOOKIE ||
req->id.idiag_cookie[1] != INET_DIAG_NOCOOKIE) &&
((u32)(unsigned long)sk != req->id.idiag_cookie[0] ||
(u32)((((unsigned long)sk) >> 31) >> 1) != req->id.idiag_cookie[1]))
goto out;
+#endif
err = -ENOMEM;
rep = alloc_skb(NLMSG_SPACE((sizeof(struct inet_diag_msg) +
@@ -578,8 +593,14 @@ static int inet_diag_fill_req(struct sk_
r->idiag_retrans = req->retrans;
r->id.idiag_if = sk->sk_bound_dev_if;
+
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+ r->id.idiag_cookie[0] = 0;
+ r->id.idiag_cookie[1] = 0;
+#else
r->id.idiag_cookie[0] = (u32)(unsigned long)req;
r->id.idiag_cookie[1] = (u32)(((unsigned long)req >> 31) >> 1);
+#endif
tmo = req->expires - jiffies;
if (tmo < 0)
diff -urNp linux-2.6.36/net/ipv4/tcp_ipv4.c linux-2.6.36/net/ipv4/tcp_ipv4.c
--- linux-2.6.36/net/ipv4/tcp_ipv4.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/net/ipv4/tcp_ipv4.c 2010-11-06 19:08:40.000000000 -0400
@@ -2400,7 +2400,11 @@ static void get_openreq4(struct sock *sk
0, /* non standard timer */
0, /* open_requests have no inode */
atomic_read(&sk->sk_refcnt),
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+ NULL,
+#else
req,
+#endif
len);
}
@@ -2450,7 +2454,12 @@ static void get_tcp4_sock(struct sock *s
sock_i_uid(sk),
icsk->icsk_probes_out,
sock_i_ino(sk),
- atomic_read(&sk->sk_refcnt), sk,
+ atomic_read(&sk->sk_refcnt),
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+ NULL,
+#else
+ sk,
+#endif
jiffies_to_clock_t(icsk->icsk_rto),
jiffies_to_clock_t(icsk->icsk_ack.ato),
(icsk->icsk_ack.quick << 1) | icsk->icsk_ack.pingpong,
@@ -2478,7 +2487,13 @@ static void get_timewait4_sock(struct in
" %02X %08X:%08X %02X:%08lX %08X %5d %8d %d %d %p%n",
i, src, srcp, dest, destp, tw->tw_substate, 0, 0,
3, jiffies_to_clock_t(ttd), 0, 0, 0, 0,
- atomic_read(&tw->tw_refcnt), tw, len);
+ atomic_read(&tw->tw_refcnt),
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+ NULL,
+#else
+ tw,
+#endif
+ len);
}
#define TMPSZ 150
diff -urNp linux-2.6.36/net/ipv4/udp.c linux-2.6.36/net/ipv4/udp.c
--- linux-2.6.36/net/ipv4/udp.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/net/ipv4/udp.c 2010-11-06 18:58:50.000000000 -0400
@@ -2051,7 +2051,12 @@ static void udp4_format_sock(struct sock
sk_wmem_alloc_get(sp),
sk_rmem_alloc_get(sp),
0, 0L, 0, sock_i_uid(sp), 0, sock_i_ino(sp),
- atomic_read(&sp->sk_refcnt), sp,
+ atomic_read(&sp->sk_refcnt),
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+ NULL,
+#else
+ sp,
+#endif
atomic_read(&sp->sk_drops), len);
}
diff -urNp linux-2.6.36/net/ipv6/raw.c linux-2.6.36/net/ipv6/raw.c
--- linux-2.6.36/net/ipv6/raw.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/net/ipv6/raw.c 2010-11-06 18:58:50.000000000 -0400
@@ -1243,7 +1243,13 @@ static void raw6_sock_seq_show(struct se
0, 0L, 0,
sock_i_uid(sp), 0,
sock_i_ino(sp),
- atomic_read(&sp->sk_refcnt), sp, atomic_read(&sp->sk_drops));
+ atomic_read(&sp->sk_refcnt),
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+ NULL,
+#else
+ sp,
+#endif
+ atomic_read(&sp->sk_drops));
}
static int raw6_seq_show(struct seq_file *seq, void *v)
diff -urNp linux-2.6.36/net/ipv6/tcp_ipv6.c linux-2.6.36/net/ipv6/tcp_ipv6.c
--- linux-2.6.36/net/ipv6/tcp_ipv6.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/net/ipv6/tcp_ipv6.c 2010-11-06 18:58:50.000000000 -0400
@@ -1987,7 +1987,13 @@ static void get_openreq6(struct seq_file
uid,
0, /* non standard timer */
0, /* open_requests have no inode */
- 0, req);
+ 0,
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+ NULL
+#else
+ req
+#endif
+ );
}
static void get_tcp6_sock(struct seq_file *seq, struct sock *sp, int i)
@@ -2037,7 +2043,12 @@ static void get_tcp6_sock(struct seq_fil
sock_i_uid(sp),
icsk->icsk_probes_out,
sock_i_ino(sp),
- atomic_read(&sp->sk_refcnt), sp,
+ atomic_read(&sp->sk_refcnt),
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+ NULL,
+#else
+ sp,
+#endif
jiffies_to_clock_t(icsk->icsk_rto),
jiffies_to_clock_t(icsk->icsk_ack.ato),
(icsk->icsk_ack.quick << 1 ) | icsk->icsk_ack.pingpong,
@@ -2072,7 +2083,13 @@ static void get_timewait6_sock(struct se
dest->s6_addr32[2], dest->s6_addr32[3], destp,
tw->tw_substate, 0, 0,
3, jiffies_to_clock_t(ttd), 0, 0, 0, 0,
- atomic_read(&tw->tw_refcnt), tw);
+ atomic_read(&tw->tw_refcnt),
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+ NULL
+#else
+ tw
+#endif
+ );
}
static int tcp6_seq_show(struct seq_file *seq, void *v)
diff -urNp linux-2.6.36/net/ipv6/udp.c linux-2.6.36/net/ipv6/udp.c
--- linux-2.6.36/net/ipv6/udp.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/net/ipv6/udp.c 2010-11-06 18:58:50.000000000 -0400
@@ -1399,7 +1399,12 @@ static void udp6_sock_seq_show(struct se
0, 0L, 0,
sock_i_uid(sp), 0,
sock_i_ino(sp),
- atomic_read(&sp->sk_refcnt), sp,
+ atomic_read(&sp->sk_refcnt),
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+ NULL,
+#else
+ sp,
+#endif
atomic_read(&sp->sk_drops));
}
diff -urNp linux-2.6.36/net/key/af_key.c linux-2.6.36/net/key/af_key.c
--- linux-2.6.36/net/key/af_key.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/net/key/af_key.c 2010-11-06 18:58:50.000000000 -0400
@@ -3644,7 +3644,11 @@ static int pfkey_seq_show(struct seq_fil
seq_printf(f ,"sk RefCnt Rmem Wmem User Inode\n");
else
seq_printf(f ,"%p %-6d %-6u %-6u %-6u %-6lu\n",
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+ NULL,
+#else
s,
+#endif
atomic_read(&s->sk_refcnt),
sk_rmem_alloc_get(s),
sk_wmem_alloc_get(s),
diff -urNp linux-2.6.36/net/netlink/af_netlink.c linux-2.6.36/net/netlink/af_netlink.c
--- linux-2.6.36/net/netlink/af_netlink.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/net/netlink/af_netlink.c 2010-11-06 18:58:50.000000000 -0400
@@ -2007,13 +2007,21 @@ static int netlink_seq_show(struct seq_f
struct netlink_sock *nlk = nlk_sk(s);
seq_printf(seq, "%p %-3d %-6d %08x %-8d %-8d %p %-8d %-8d %-8lu\n",
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+ NULL,
+#else
s,
+#endif
s->sk_protocol,
nlk->pid,
nlk->groups ? (u32)nlk->groups[0] : 0,
sk_rmem_alloc_get(s),
sk_wmem_alloc_get(s),
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+ NULL,
+#else
nlk->cb,
+#endif
atomic_read(&s->sk_refcnt),
atomic_read(&s->sk_drops),
sock_i_ino(s)
diff -urNp linux-2.6.36/net/packet/af_packet.c linux-2.6.36/net/packet/af_packet.c
--- linux-2.6.36/net/packet/af_packet.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/net/packet/af_packet.c 2010-11-06 18:58:50.000000000 -0400
@@ -2637,7 +2637,11 @@ static int packet_seq_show(struct seq_fi
seq_printf(seq,
"%p %-6d %-4d %04x %-5d %1d %-6u %-6u %-6lu\n",
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+ NULL,
+#else
s,
+#endif
atomic_read(&s->sk_refcnt),
s->sk_type,
ntohs(po->num),
diff -urNp linux-2.6.36/net/phonet/socket.c linux-2.6.36/net/phonet/socket.c
--- linux-2.6.36/net/phonet/socket.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/net/phonet/socket.c 2010-11-13 16:29:01.000000000 -0500
@@ -535,7 +535,12 @@ static int pn_sock_seq_show(struct seq_f
sk->sk_state,
sk_wmem_alloc_get(sk), sk_rmem_alloc_get(sk),
sock_i_uid(sk), sock_i_ino(sk),
- atomic_read(&sk->sk_refcnt), sk,
+ atomic_read(&sk->sk_refcnt),
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+ NULL,
+#else
+ sk,
+#endif
atomic_read(&sk->sk_drops), &len);
}
seq_printf(seq, "%*s\n", 127 - len, "");
diff -urNp linux-2.6.36/net/sctp/proc.c linux-2.6.36/net/sctp/proc.c
--- linux-2.6.36/net/sctp/proc.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/net/sctp/proc.c 2010-11-13 16:29:01.000000000 -0500
@@ -212,7 +212,12 @@ static int sctp_eps_seq_show(struct seq_
sctp_for_each_hentry(epb, node, &head->chain) {
ep = sctp_ep(epb);
sk = epb->sk;
- seq_printf(seq, "%8p %8p %-3d %-3d %-4d %-5d %5d %5lu ", ep, sk,
+ seq_printf(seq, "%8p %8p %-3d %-3d %-4d %-5d %5d %5lu ",
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+ NULL, NULL,
+#else
+ ep, sk,
+#endif
sctp_sk(sk)->type, sk->sk_state, hash,
epb->bind_addr.port,
sock_i_uid(sk), sock_i_ino(sk));
@@ -318,7 +323,12 @@ static int sctp_assocs_seq_show(struct s
seq_printf(seq,
"%8p %8p %-3d %-3d %-2d %-4d "
"%4d %8d %8d %7d %5lu %-5d %5d ",
- assoc, sk, sctp_sk(sk)->type, sk->sk_state,
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+ NULL, NULL,
+#else
+ assoc, sk,
+#endif
+ sctp_sk(sk)->type, sk->sk_state,
assoc->state, hash,
assoc->assoc_id,
assoc->sndbuf_used,
diff -urNp linux-2.6.36/net/unix/af_unix.c linux-2.6.36/net/unix/af_unix.c
--- linux-2.6.36/net/unix/af_unix.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/net/unix/af_unix.c 2010-11-06 20:08:14.000000000 -0400
@@ -2195,7 +2195,11 @@ static int unix_seq_show(struct seq_file
unix_state_lock(s);
seq_printf(seq, "%p: %08X %08X %08X %04X %02X %5lu",
+#ifdef CONFIG_GRKERNSEC_HIDESYM
+ NULL,
+#else
s,
+#endif
atomic_read(&s->sk_refcnt),
0,
s->sk_state == TCP_LISTEN ? __SO_ACCEPTCON : 0,
diff -urNp linux-2.6.36/arch/powerpc/kernel/process.c linux-2.6.36/arch/powerpc/kernel/process.c
--- linux-2.6.36/arch/powerpc/kernel/process.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/arch/powerpc/kernel/process.c 2010-11-13 16:29:01.000000000 -0500
@@ -654,8 +654,8 @@ void show_regs(struct pt_regs * regs)
* Lookup NIP late so we have the best change of getting the
* above info out without failing
*/
- printk("NIP ["REG"] %pS\n", regs->nip, (void *)regs->nip);
- printk("LR ["REG"] %pS\n", regs->link, (void *)regs->link);
+ printk("NIP ["REG"] %pA\n", regs->nip, (void *)regs->nip);
+ printk("LR ["REG"] %pA\n", regs->link, (void *)regs->link);
#endif
show_stack(current, (unsigned long *) regs->gpr[1]);
if (!user_mode(regs))
@@ -1145,10 +1145,10 @@ void show_stack(struct task_struct *tsk,
newsp = stack[0];
ip = stack[STACK_FRAME_LR_SAVE];
if (!firstframe || ip != lr) {
- printk("["REG"] ["REG"] %pS", sp, ip, (void *)ip);
+ printk("["REG"] ["REG"] %pA", sp, ip, (void *)ip);
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
if ((ip == rth || ip == mrth) && curr_frame >= 0) {
- printk(" (%pS)",
+ printk(" (%pA)",
(void *)current->ret_stack[curr_frame].ret);
curr_frame--;
}
@@ -1168,7 +1168,7 @@ void show_stack(struct task_struct *tsk,
struct pt_regs *regs = (struct pt_regs *)
(sp + STACK_FRAME_OVERHEAD);
lr = regs->link;
- printk("--- Exception: %lx at %pS\n LR = %pS\n",
+ printk("--- Exception: %lx at %pA\n LR = %pA\n",
regs->trap, (void *)regs->nip, (void *)lr);
firstframe = 1;
}
diff -urNp linux-2.6.36/arch/sparc/kernel/process_32.c linux-2.6.36/arch/sparc/kernel/process_32.c
--- linux-2.6.36/arch/sparc/kernel/process_32.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/arch/sparc/kernel/process_32.c 2010-11-13 16:29:01.000000000 -0500
@@ -196,7 +196,7 @@ void __show_backtrace(unsigned long fp)
rw->ins[4], rw->ins[5],
rw->ins[6],
rw->ins[7]);
- printk("%pS\n", (void *) rw->ins[7]);
+ printk("%pA\n", (void *) rw->ins[7]);
rw = (struct reg_window32 *) rw->ins[6];
}
spin_unlock_irqrestore(&sparc_backtrace_lock, flags);
@@ -263,14 +263,14 @@ void show_regs(struct pt_regs *r)
printk("PSR: %08lx PC: %08lx NPC: %08lx Y: %08lx %s\n",
r->psr, r->pc, r->npc, r->y, print_tainted());
- printk("PC: <%pS>\n", (void *) r->pc);
+ printk("PC: <%pA>\n", (void *) r->pc);
printk("%%G: %08lx %08lx %08lx %08lx %08lx %08lx %08lx %08lx\n",
r->u_regs[0], r->u_regs[1], r->u_regs[2], r->u_regs[3],
r->u_regs[4], r->u_regs[5], r->u_regs[6], r->u_regs[7]);
printk("%%O: %08lx %08lx %08lx %08lx %08lx %08lx %08lx %08lx\n",
r->u_regs[8], r->u_regs[9], r->u_regs[10], r->u_regs[11],
r->u_regs[12], r->u_regs[13], r->u_regs[14], r->u_regs[15]);
- printk("RPC: <%pS>\n", (void *) r->u_regs[15]);
+ printk("RPC: <%pA>\n", (void *) r->u_regs[15]);
printk("%%L: %08lx %08lx %08lx %08lx %08lx %08lx %08lx %08lx\n",
rw->locals[0], rw->locals[1], rw->locals[2], rw->locals[3],
@@ -305,7 +305,7 @@ void show_stack(struct task_struct *tsk,
rw = (struct reg_window32 *) fp;
pc = rw->ins[7];
printk("[%08lx : ", pc);
- printk("%pS ] ", (void *) pc);
+ printk("%pA ] ", (void *) pc);
fp = rw->ins[6];
} while (++count < 16);
printk("\n");
diff -urNp linux-2.6.36/arch/sparc/kernel/process_64.c linux-2.6.36/arch/sparc/kernel/process_64.c
--- linux-2.6.36/arch/sparc/kernel/process_64.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/arch/sparc/kernel/process_64.c 2010-11-13 16:34:22.000000000 -0500
@@ -180,14 +180,14 @@ static void show_regwindow(struct pt_reg
printk("i4: %016lx i5: %016lx i6: %016lx i7: %016lx\n",
rwk->ins[4], rwk->ins[5], rwk->ins[6], rwk->ins[7]);
if (regs->tstate & TSTATE_PRIV)
- printk("I7: <%pS>\n", (void *) rwk->ins[7]);
+ printk("I7: <%pA>\n", (void *) rwk->ins[7]);
}
void show_regs(struct pt_regs *regs)
{
printk("TSTATE: %016lx TPC: %016lx TNPC: %016lx Y: %08x %s\n", regs->tstate,
regs->tpc, regs->tnpc, regs->y, print_tainted());
- printk("TPC: <%pS>\n", (void *) regs->tpc);
+ printk("TPC: <%pA>\n", (void *) regs->tpc);
printk("g0: %016lx g1: %016lx g2: %016lx g3: %016lx\n",
regs->u_regs[0], regs->u_regs[1], regs->u_regs[2],
regs->u_regs[3]);
@@ -200,7 +200,7 @@ void show_regs(struct pt_regs *regs)
printk("o4: %016lx o5: %016lx sp: %016lx ret_pc: %016lx\n",
regs->u_regs[12], regs->u_regs[13], regs->u_regs[14],
regs->u_regs[15]);
- printk("RPC: <%pS>\n", (void *) regs->u_regs[15]);
+ printk("RPC: <%pA>\n", (void *) regs->u_regs[15]);
show_regwindow(regs);
show_stack(current, (unsigned long *) regs->u_regs[UREG_FP]);
}
@@ -285,7 +285,7 @@ void arch_trigger_all_cpu_backtrace(void
((tp && tp->task) ? tp->task->pid : -1));
if (gp->tstate & TSTATE_PRIV) {
- printk(" TPC[%pS] O7[%pS] I7[%pS] RPC[%pS]\n",
+ printk(" TPC[%pA] O7[%pA] I7[%pA] RPC[%pA]\n",
(void *) gp->tpc,
(void *) gp->o7,
(void *) gp->i7,
diff -urNp linux-2.6.36/arch/sparc/kernel/traps_32.c linux-2.6.36/arch/sparc/kernel/traps_32.c
--- linux-2.6.36/arch/sparc/kernel/traps_32.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/arch/sparc/kernel/traps_32.c 2010-11-13 16:29:01.000000000 -0500
@@ -76,7 +76,7 @@ void die_if_kernel(char *str, struct pt_
count++ < 30 &&
(((unsigned long) rw) >= PAGE_OFFSET) &&
!(((unsigned long) rw) & 0x7)) {
- printk("Caller[%08lx]: %pS\n", rw->ins[7],
+ printk("Caller[%08lx]: %pA\n", rw->ins[7],
(void *) rw->ins[7]);
rw = (struct reg_window32 *)rw->ins[6];
}
diff -urNp linux-2.6.36/arch/sparc/kernel/traps_64.c linux-2.6.36/arch/sparc/kernel/traps_64.c
--- linux-2.6.36/arch/sparc/kernel/traps_64.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/arch/sparc/kernel/traps_64.c 2010-11-13 16:34:06.000000000 -0500
@@ -75,7 +75,7 @@ static void dump_tl1_traplog(struct tl1_
i + 1,
p->trapstack[i].tstate, p->trapstack[i].tpc,
p->trapstack[i].tnpc, p->trapstack[i].tt);
- printk("TRAPLOG: TPC<%pS>\n", (void *) p->trapstack[i].tpc);
+ printk("TRAPLOG: TPC<%pA>\n", (void *) p->trapstack[i].tpc);
}
}
@@ -1141,7 +1141,7 @@ static void cheetah_log_errors(struct pt
regs->tpc, regs->tnpc, regs->u_regs[UREG_I7], regs->tstate);
printk("%s" "ERROR(%d): ",
(recoverable ? KERN_WARNING : KERN_CRIT), smp_processor_id());
- printk("TPC<%pS>\n", (void *) regs->tpc);
+ printk("TPC<%pA>\n", (void *) regs->tpc);
printk("%s" "ERROR(%d): M_SYND(%lx), E_SYND(%lx)%s%s\n",
(recoverable ? KERN_WARNING : KERN_CRIT), smp_processor_id(),
(afsr & CHAFSR_M_SYNDROME) >> CHAFSR_M_SYNDROME_SHIFT,
@@ -1748,7 +1748,7 @@ void cheetah_plus_parity_error(int type,
smp_processor_id(),
(type & 0x1) ? 'I' : 'D',
regs->tpc);
- printk(KERN_EMERG "TPC<%pS>\n", (void *) regs->tpc);
+ printk(KERN_EMERG "TPC<%pA>\n", (void *) regs->tpc);
panic("Irrecoverable Cheetah+ parity error.");
}
@@ -1756,7 +1756,7 @@ void cheetah_plus_parity_error(int type,
smp_processor_id(),
(type & 0x1) ? 'I' : 'D',
regs->tpc);
- printk(KERN_WARNING "TPC<%pS>\n", (void *) regs->tpc);
+ printk(KERN_WARNING "TPC<%pA>\n", (void *) regs->tpc);
}
struct sun4v_error_entry {
@@ -1963,9 +1963,9 @@ void sun4v_itlb_error_report(struct pt_r
printk(KERN_EMERG "SUN4V-ITLB: Error at TPC[%lx], tl %d\n",
regs->tpc, tl);
- printk(KERN_EMERG "SUN4V-ITLB: TPC<%pS>\n", (void *) regs->tpc);
+ printk(KERN_EMERG "SUN4V-ITLB: TPC<%pA>\n", (void *) regs->tpc);
printk(KERN_EMERG "SUN4V-ITLB: O7[%lx]\n", regs->u_regs[UREG_I7]);
- printk(KERN_EMERG "SUN4V-ITLB: O7<%pS>\n",
+ printk(KERN_EMERG "SUN4V-ITLB: O7<%pA>\n",
(void *) regs->u_regs[UREG_I7]);
printk(KERN_EMERG "SUN4V-ITLB: vaddr[%lx] ctx[%lx] "
"pte[%lx] error[%lx]\n",
@@ -1987,9 +1987,9 @@ void sun4v_dtlb_error_report(struct pt_r
printk(KERN_EMERG "SUN4V-DTLB: Error at TPC[%lx], tl %d\n",
regs->tpc, tl);
- printk(KERN_EMERG "SUN4V-DTLB: TPC<%pS>\n", (void *) regs->tpc);
+ printk(KERN_EMERG "SUN4V-DTLB: TPC<%pA>\n", (void *) regs->tpc);
printk(KERN_EMERG "SUN4V-DTLB: O7[%lx]\n", regs->u_regs[UREG_I7]);
- printk(KERN_EMERG "SUN4V-DTLB: O7<%pS>\n",
+ printk(KERN_EMERG "SUN4V-DTLB: O7<%pA>\n",
(void *) regs->u_regs[UREG_I7]);
printk(KERN_EMERG "SUN4V-DTLB: vaddr[%lx] ctx[%lx] "
"pte[%lx] error[%lx]\n",
@@ -2196,13 +2196,13 @@ void show_stack(struct task_struct *tsk,
fp = (unsigned long)sf->fp + STACK_BIAS;
}
- printk(" [%016lx] %pS\n", pc, (void *) pc);
+ printk(" [%016lx] %pA\n", pc, (void *) pc);
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
if ((pc + 8UL) == (unsigned long) &return_to_handler) {
int index = tsk->curr_ret_stack;
if (tsk->ret_stack && index >= graph) {
pc = tsk->ret_stack[index - graph].ret;
- printk(" [%016lx] %pS\n", pc, (void *) pc);
+ printk(" [%016lx] %pA\n", pc, (void *) pc);
graph++;
}
}
@@ -2255,7 +2255,7 @@ void die_if_kernel(char *str, struct pt_
while (rw &&
count++ < 30 &&
kstack_valid(tp, (unsigned long) rw)) {
- printk("Caller[%016lx]: %pS\n", rw->ins[7],
+ printk("Caller[%016lx]: %pA\n", rw->ins[7],
(void *) rw->ins[7]);
rw = kernel_stack_up(rw);
diff -urNp linux-2.6.36/arch/sparc/kernel/unaligned_64.c linux-2.6.36/arch/sparc/kernel/unaligned_64.c
--- linux-2.6.36/arch/sparc/kernel/unaligned_64.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/arch/sparc/kernel/unaligned_64.c 2010-11-13 16:33:46.000000000 -0500
@@ -278,7 +278,7 @@ static void log_unaligned(struct pt_regs
static DEFINE_RATELIMIT_STATE(ratelimit, 5 * HZ, 5);
if (__ratelimit(&ratelimit)) {
- printk("Kernel unaligned access at TPC[%lx] %pS\n",
+ printk("Kernel unaligned access at TPC[%lx] %pA\n",
regs->tpc, (void *) regs->tpc);
}
}
diff -urNp linux-2.6.36/arch/sparc/mm/fault_64.c linux-2.6.36/arch/sparc/mm/fault_64.c
--- linux-2.6.36/arch/sparc/mm/fault_64.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/arch/sparc/mm/fault_64.c 2010-11-13 16:29:01.000000000 -0500
@@ -74,7 +74,7 @@ static void __kprobes bad_kernel_pc(stru
printk(KERN_CRIT "OOPS: Bogus kernel PC [%016lx] in fault handler\n",
regs->tpc);
printk(KERN_CRIT "OOPS: RPC [%016lx]\n", regs->u_regs[15]);
- printk("OOPS: RPC <%pS>\n", (void *) regs->u_regs[15]);
+ printk("OOPS: RPC <%pA>\n", (void *) regs->u_regs[15]);
printk(KERN_CRIT "OOPS: Fault was to vaddr[%lx]\n", vaddr);
dump_stack();
unhandled_fault(regs->tpc, current, regs);
diff -urNp linux-2.6.36/arch/x86/kernel/dumpstack.c linux-2.6.36/arch/x86/kernel/dumpstack.c
--- linux-2.6.36/arch/x86/kernel/dumpstack.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/arch/x86/kernel/dumpstack.c 2010-11-13 16:29:01.000000000 -0500
@@ -27,7 +27,7 @@ static int die_counter;
void printk_address(unsigned long address, int reliable)
{
- printk(" [<%p>] %s%pS\n", (void *) address,
+ printk(" [<%p>] %s%pA\n", (void *) address,
reliable ? "" : "? ", (void *) address);
}
diff -urNp linux-2.6.36/kernel/panic.c linux-2.6.36/kernel/panic.c
--- linux-2.6.36/kernel/panic.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/kernel/panic.c 2010-11-13 16:29:01.000000000 -0500
@@ -368,7 +368,7 @@ static void warn_slowpath_common(const c
const char *board;
printk(KERN_WARNING "------------[ cut here ]------------\n");
- printk(KERN_WARNING "WARNING: at %s:%d %pS()\n", file, line, caller);
+ printk(KERN_WARNING "WARNING: at %s:%d %pA()\n", file, line, caller);
board = dmi_get_system_info(DMI_PRODUCT_NAME);
if (board)
printk(KERN_WARNING "Hardware name: %s\n", board);
@@ -423,7 +423,8 @@ EXPORT_SYMBOL(warn_slowpath_null);
*/
void __stack_chk_fail(void)
{
- panic("stack-protector: Kernel stack is corrupted in: %p\n",
+ dump_stack();
+ panic("stack-protector: Kernel stack is corrupted in: %pA\n",
__builtin_return_address(0));
}
EXPORT_SYMBOL(__stack_chk_fail);
diff -urNp linux-2.6.36/mm/kmemleak.c linux-2.6.36/mm/kmemleak.c
--- linux-2.6.36/mm/kmemleak.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/mm/kmemleak.c 2010-11-13 16:29:01.000000000 -0500
@@ -355,7 +355,7 @@ static void print_unreferenced(struct se
for (i = 0; i < object->trace_len; i++) {
void *ptr = (void *)object->trace[i];
- seq_printf(seq, " [<%p>] %pS\n", ptr, ptr);
+ seq_printf(seq, " [<%p>] %pA\n", ptr, ptr);
}
}
diff -urNp linux-2.6.36/mm/slub.c linux-2.6.36/mm/slub.c
--- linux-2.6.36/mm/slub.c 2010-10-20 16:30:22.000000000 -0400
+++ linux-2.6.36/mm/slub.c 2010-11-13 16:29:01.000000000 -0500
@@ -392,7 +392,7 @@ static void print_track(const char *s, s
if (!t->addr)
return;
- printk(KERN_ERR "INFO: %s in %pS age=%lu cpu=%u pid=%d\n",
+ printk(KERN_ERR "INFO: %s in %pA age=%lu cpu=%u pid=%d\n",
s, (void *)t->addr, jiffies - t->when, t->cpu, t->pid);
}
--
Kees Cook
Ubuntu Security Team
Sorry for being late to join this thread.
I thought I'd also mention that if you can insert a small amount of
shell code into the kernel, it's trivial to search kernel memory for
the symbol table and derive anything else you want from that.
I wrote some proof of concept code to do this a few years ago[1]. I'm
pretty sure you could compress this down to a few bytes of assembler.
(Plus I don't think that removing pointers is a good idea anyway -- it
just breaks userspace tools, and any real world system is going to be
running a well-known kernel that can be downloaded from some mirror
somewhere)
Rich.
[1] It's a poor example, but in here is code that searched for ksyms
and kallsyms in 32 bit i386 kernels (files virt_mem_ksyms.ml and
virt_mem_kallsyms.ml).
http://git.annexia.org/?p=virt-mem.git;a=tree;f=lib;hb=HEAD
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
On 11/17/2010 07:40 AM, Kyle Moffett wrote:
> (1) For 99%+ of all the computers out there you can get a 90%+
> accurate guess for what kernel is running by looking at the version of
> libc installed on the system. All you have to do for those computers
> is download a bunch of distro kernels and look at the libc packages
> and build a table of "libc6-SOMEVERSION => 0xADDRESS", etc. Because
> of how all the vendors backport and track versions, "SOMEVERSION"
> usually includes something wonderfully helpful like "el5" or "squeeze"
> or whatever. This does *nothing* for those users, and it's not clear
> that it ever *could*.
Isn't the kernel relocatable these days? We can randomize the kernel
load address at boot time and make this information useless.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
On Fri, 19 Nov 2010, Kees Cook wrote:
> On Fri, Nov 19, 2010 at 03:22:00PM -0800, Linus Torvalds wrote:
> > In this case, the upside just wasn't big enough to accept _any_
> > breakage, especially since people and distributions can just do the
> > "chmod" themselves if they want to. There was a lot of discussion
> > whether the patch should even go in in the first place. So this time,
> > the "let's just revert it" was a very easy decision for me.
>
> The downside is that /proc can be remounted multiple times for different
> containers, etc. Having to patch everything that mounts /proc to do the
> chmod seems much more painful that fixing a simple userspace bug in an old
> klog daemon.
>
> (For example, rsyslogd handles this fine since it's root to open it, and
> even if it fails, it doesn't do the broken fclose().)
If it is a pain only for buggy old/legacy userspace like klogd or a few
tools, it would still be very useful as a Kconfig option defaulting to
disabled.
As an user and sysadmin, I'd rather not have to find out every place that
mounts /proc in a chroot to chmod all relevant files :( That's fighting a
loosing battle, unlike fixing broken tools (which at least will stay fixed).
Distros could get any fixing done they require, and then enable it for all
their users. Ubuntu and Debian are likely to do it, and I'd guess so is
Fedora.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Hi!
> > (2) Most of the arguments about introducing "uncertainty" into the
> > hacking process are specious as well. [...]
>
> It is only specious if you ignore the arguments i made in the previous
> discussion. One argument i made was:
Well, but it has downsides, too.
If I know school server is vulnerable, I can get admin to fix it... if
I can see dmesg without being root, I can help with problems. I have
done both before...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
* Pavel Machek <[email protected]> wrote:
> Hi!
>
> > > (2) Most of the arguments about introducing "uncertainty" into the
> > > hacking process are specious as well. [...]
> >
> > It is only specious if you ignore the arguments i made in the previous
> > discussion. One argument i made was:
>
> Well, but it has downsides, too.
>
> If I know school server is vulnerable, I can get admin to fix it... if
> I can see dmesg without being root, I can help with problems. I have
> done both before...
Yeah, restricting information is always a double edged sword - and by locking down
we are implicitly assuming that the number of people trying to do harm is larger
than the number of people trying to help. It is probably true though - and the
damage they can inflict is becoming more and more serious (financially, legally and
socially - and, in some cases, physically) with every year of humanity moving their
lives to the 'net.
So yes, the time has probably come to lock up "potentially harmful" information from
the default unprivileged user on Linux - at least from a default kernel policies
POV.
Thanks,
Ingo
* Linus Torvalds <[email protected]> wrote:
> On Fri, Nov 19, 2010 at 11:19 AM, Sarah Sharp
> <[email protected]> wrote:
> >
> > .config and dmesg are attached. ?The box is running klogd 1.5.5ubuntu3
> > (from Jaunty). ?Yes, I know that's old. ?I read the bit in the commit
> > about changing the permissions of kallsyms after boot, but if I can't
> > boot that doesn't help. ?Perhaps this can be made a configuration
> > option?
>
> It's not worth a config option.
>
> If it actually breaks user-space, I think we should just revert it.
Sarah,
Does your system boot fine if we make /proc/kallsyms simply an empty file to
unprivileged users? Something like the (untested ...) patch below.
Ingo
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 6f6d091..d54c993 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -465,7 +465,7 @@ static int s_show(struct seq_file *m, void *p)
struct kallsym_iter *iter = m->private;
/* Some debugging symbols have no name. Ignore them. */
- if (!iter->name[0])
+ if (!iter->name[0] || !capable(CAP_SYS_ADMIN))
return 0;
if (iter->module_name[0]) {
* Kees Cook <[email protected]> wrote:
> On Thu, Nov 18, 2010 at 08:48:04AM +0100, Ingo Molnar wrote:
> > Agreed. A few other kernel address things that should be hidden are:
> > [snip]
>
> For reference, here's what GRKERNSEC_HIDESYM looks like in grsecurity.
> It's quite a sledgehammer, but it does help to point out at least the
> minimum number of things that need fixing.
Yeah, it's a somewhat disgusting patch - but it also looks useful.
It would be more palatable for upstream if it was:
- split up
- if all those GRKERNSEC_HIDESYM #ifdefs were removed, either by making the
grsecurity defaults the default behavior, or by intelligently hiding it behinds
wrappers.
I'd suggest a single CONFIG_LEGACY_SYMBOLS=y config option for this, but only used
to show those symbols that are absolutely needed for compatibility - like
/proc/kallsyms. (Newer distros could disable this option and the kernel could
eventually default to it being disabled as well.)
Also, while changing hexa output to symbolic output is fine, changing the oops
output is borderline - that is an absolutely useful piece of information that helps
us in decoding crashes. So i'd suggest to split that into a super-paranoid option or
so.
Anyway, after a split-up we'll see how good the individual bits are - it's a bit of
a mixed bag right now.
Thanks,
Ingo
On Fri, Nov 26, 2010 at 08:48:09AM +0100, Ingo Molnar wrote:
>
> * Linus Torvalds <[email protected]> wrote:
>
> > On Fri, Nov 19, 2010 at 11:19 AM, Sarah Sharp
> > <[email protected]> wrote:
> > >
> > > .config and dmesg are attached. ?The box is running klogd 1.5.5ubuntu3
> > > (from Jaunty). ?Yes, I know that's old. ?I read the bit in the commit
> > > about changing the permissions of kallsyms after boot, but if I can't
> > > boot that doesn't help. ?Perhaps this can be made a configuration
> > > option?
> >
> > It's not worth a config option.
> >
> > If it actually breaks user-space, I think we should just revert it.
>
> Sarah,
>
> Does your system boot fine if we make /proc/kallsyms simply an empty file to
> unprivileged users? Something like the (untested ...) patch below.
Yes, that works. The system boots as normal. `cat /proc/kallsyms`
returns an empty file, and `sudo cat /proc/kallsyms` does not.
Sarah Sharp
> diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
> index 6f6d091..d54c993 100644
> --- a/kernel/kallsyms.c
> +++ b/kernel/kallsyms.c
> @@ -465,7 +465,7 @@ static int s_show(struct seq_file *m, void *p)
> struct kallsym_iter *iter = m->private;
>
> /* Some debugging symbols have no name. Ignore them. */
> - if (!iter->name[0])
> + if (!iter->name[0] || !capable(CAP_SYS_ADMIN))
> return 0;
>
> if (iter->module_name[0]) {
* Sarah Sharp <[email protected]> wrote:
> On Fri, Nov 26, 2010 at 08:48:09AM +0100, Ingo Molnar wrote:
> >
> > * Linus Torvalds <[email protected]> wrote:
> >
> > > On Fri, Nov 19, 2010 at 11:19 AM, Sarah Sharp
> > > <[email protected]> wrote:
> > > >
> > > > .config and dmesg are attached. ?The box is running klogd 1.5.5ubuntu3
> > > > (from Jaunty). ?Yes, I know that's old. ?I read the bit in the commit
> > > > about changing the permissions of kallsyms after boot, but if I can't
> > > > boot that doesn't help. ?Perhaps this can be made a configuration
> > > > option?
> > >
> > > It's not worth a config option.
> > >
> > > If it actually breaks user-space, I think we should just revert it.
> >
> > Sarah,
> >
> > Does your system boot fine if we make /proc/kallsyms simply an empty file to
> > unprivileged users? Something like the (untested ...) patch below.
>
> Yes, that works. The system boots as normal. `cat /proc/kallsyms`
> returns an empty file, and `sudo cat /proc/kallsyms` does not.
Great! Marcus, mind respinning your patch with that approach?
Thanks,
Ingo
On 11/25/2010 11:38 PM, Ingo Molnar wrote:
>
> Yeah, restricting information is always a double edged sword - and by locking down
> we are implicitly assuming that the number of people trying to do harm is larger
> than the number of people trying to help. It is probably true though - and the
> damage they can inflict is becoming more and more serious (financially, legally and
> socially - and, in some cases, physically) with every year of humanity moving their
> lives to the 'net.
>
> So yes, the time has probably come to lock up "potentially harmful" information from
> the default unprivileged user on Linux - at least from a default kernel policies
> POV.
>
The setting of these policies needs to be figured out sensibly.
One of my great complaints about several Linux distributions is that
they keep forcing log files to be readable only by root, even though
they do put the adm group in their default group file -- the adm group
is traditionally the group allowed to read log files.
It is a *good* thing for a *restricted set* of users to have *readonly*
access to this kind of information -- i.e., a group. It is *not* a good
thing for system security or reliability to force the administrator to
assert root privileges to merely monitor information.
-hpa
On 11/29/2010 10:04 AM, Ingo Molnar wrote:
>
> * Sarah Sharp <[email protected]> wrote:
>
>> On Fri, Nov 26, 2010 at 08:48:09AM +0100, Ingo Molnar wrote:
>>>
>>> * Linus Torvalds <[email protected]> wrote:
>>>
>>>> On Fri, Nov 19, 2010 at 11:19 AM, Sarah Sharp
>>>> <[email protected]> wrote:
>>>>>
>>>>> .config and dmesg are attached. The box is running klogd 1.5.5ubuntu3
>>>>> (from Jaunty). Yes, I know that's old. I read the bit in the commit
>>>>> about changing the permissions of kallsyms after boot, but if I can't
>>>>> boot that doesn't help. Perhaps this can be made a configuration
>>>>> option?
>>>>
>>>> It's not worth a config option.
>>>>
>>>> If it actually breaks user-space, I think we should just revert it.
>>>
>>> Sarah,
>>>
>>> Does your system boot fine if we make /proc/kallsyms simply an empty file to
>>> unprivileged users? Something like the (untested ...) patch below.
>>
>> Yes, that works. The system boots as normal. `cat /proc/kallsyms`
>> returns an empty file, and `sudo cat /proc/kallsyms` does not.
>
> Great! Marcus, mind respinning your patch with that approach?
>
Can we please not use CAP_SYS_ADMIN for this? Relying on CAP_SYS_ADMIN
is worse than anything else -- it is a fixed policy hardcoded in the
kernel, with no ability for the system owner to delegate the policy
outward, e.g. by adding group read permission and/or chgrp the file.
Delegating CAP_SYS_ADMIN, of course, otherwise known as "everything", is
worse than anything...
-hpa
On Mon, Nov 29, 2010 at 2:05 PM, H. Peter Anvin <[email protected]> wrote:
> On 11/29/2010 10:04 AM, Ingo Molnar wrote:
>>
>> * Sarah Sharp <[email protected]> wrote:
>>
>>> On Fri, Nov 26, 2010 at 08:48:09AM +0100, Ingo Molnar wrote:
>>>> Sarah,
>>>>
>>>> Does your system boot fine if we make /proc/kallsyms simply an empty file to
>>>> unprivileged users? Something like the (untested ...) patch below.
>>>
>>> Yes, that works. ?The system boots as normal. `cat /proc/kallsyms`
>>> returns an empty file, and `sudo cat /proc/kallsyms` does not.
>>
>> Great! Marcus, mind respinning your patch with that approach?
>>
>
> Can we please not use CAP_SYS_ADMIN for this? ?Relying on CAP_SYS_ADMIN
> is worse than anything else -- it is a fixed policy hardcoded in the
> kernel, with no ability for the system owner to delegate the policy
> outward, e.g. by adding group read permission and/or chgrp the file.
>
> Delegating CAP_SYS_ADMIN, of course, otherwise known as "everything", is
> worse than anything...
Serge just proposed a new CAP_SYSLOG
http://lwn.net/Articles/378472/
Which could probably still be renamed and used to cover this access as well....
On 11/29/2010 11:21 AM, Eric Paris wrote:
>>
>> Delegating CAP_SYS_ADMIN, of course, otherwise known as "everything", is
>> worse than anything...
>
> Serge just proposed a new CAP_SYSLOG
>
> http://lwn.net/Articles/378472/
>
> Which could probably still be renamed and used to cover this access as well....
>
Quite frankly, the Linux capability system is largely a mess, with big
bundled capacities that don't make much sense and are hideously
inconvenient with the capability system used in user space (groups).
For things like this that genuinely has a file node, *let's use it* and
allow permissions to be controlled by the file node!
-hpa
On Mon, Nov 29, 2010 at 11:05:58AM -0800, H. Peter Anvin wrote:
> Can we please not use CAP_SYS_ADMIN for this? Relying on CAP_SYS_ADMIN
> is worse than anything else -- it is a fixed policy hardcoded in the
> kernel, with no ability for the system owner to delegate the policy
> outward, e.g. by adding group read permission and/or chgrp the file.
>
> Delegating CAP_SYS_ADMIN, of course, otherwise known as "everything", is
> worse than anything...
Agreed, that's why I still think that hiding lots of valuable information to
non-root users will get more users added to unmanaged sudoers files, which
will result in much more holes in the systems than we currently have.
Willy
On Sat, Nov 20, 2010 at 05:47:23PM -0200, Henrique de Moraes Holschuh wrote:
> On Fri, 19 Nov 2010, Kees Cook wrote:
> > On Fri, Nov 19, 2010 at 03:22:00PM -0800, Linus Torvalds wrote:
> > > In this case, the upside just wasn't big enough to accept _any_
> > > breakage, especially since people and distributions can just do the
> > > "chmod" themselves if they want to. There was a lot of discussion
> > > whether the patch should even go in in the first place. So this time,
> > > the "let's just revert it" was a very easy decision for me.
> >
> > The downside is that /proc can be remounted multiple times for different
> > containers, etc. Having to patch everything that mounts /proc to do the
> > chmod seems much more painful that fixing a simple userspace bug in an old
> > klog daemon.
> >
>
> As an user and sysadmin, I'd rather not have to find out every place that
> mounts /proc in a chroot to chmod all relevant files :( That's fighting a
> loosing battle, unlike fixing broken tools (which at least will stay fixed).
There's only one set of "kallsyms" permissions. If you chmod it in one
mount of proc, the permissions apply in *all* mounts of proc, current
or future.
So you don't have to find every place that mounts /proc - you can just
chmod it once at startup and be done.
- Kevin
> > /* Some debugging symbols have no name. Ignore them. */
> > - if (!iter->name[0])
> > + if (!iter->name[0] || !capable(CAP_SYS_ADMIN))
> > return 0;
This is hardcoding file permission policy into the kernel in a way the
user cannot change - its bogus in the extreme. Use file permissions that
way saner people can chmod them as they like. Indeed quite a few people
*already* chmod chunks of /proc.
It also means that things like SELinux and Tomoyo can be used to manage
security on it in clever ways - something that using a capability
completely buggers up.
Alan
* Alan Cox <[email protected]> wrote:
> > > /* Some debugging symbols have no name. Ignore them. */
> > > - if (!iter->name[0])
> > > + if (!iter->name[0] || !capable(CAP_SYS_ADMIN))
> > > return 0;
>
> This is hardcoding file permission policy into the kernel in a way the
> user cannot change - its bogus in the extreme. Use file permissions that
> way saner people can chmod them as they like. Indeed quite a few people
> *already* chmod chunks of /proc.
Peter already pointed that out and i agree.
The main goal here was to establish that a regression-free patch can be implemented
by giving user-space a *empty /proc/kallsyms file* - that we older systems do not
crash on bootup.
> It also means that things like SELinux and Tomoyo can be used to manage security
> on it in clever ways - something that using a capability completely buggers up.
Frankly, our security interfaces are a mess - i did not even try to figure out the
'right' way to do it. Modularization of security subsystem made it all distinctly
worse.
Why dont we have coherent, easy to use (and hard to mess up) security interfaces to
begin with? The moment a kernel developer has to think of:
retval = -EPERM;
if (capable(CAP_SETUID)) {
new->suid = new->uid = uid;
if (uid != old->uid) {
retval = set_user(new);
if (retval < 0)
goto error;
}
} else if (uid != old->uid && uid != new->suid) {
goto error;
}
new->fsuid = new->euid = uid;
retval = security_task_fix_setuid(new, old, LSM_SETID_ID);
if (retval < 0)
goto error;
As the 'secure' implementation of a piece of kernel logic we have lost the
'security' battle ...
The current security callbacks are absolutely nonsensical random crap slapped all
around the kernel. It increases our security complexity and has thus the opposite
effect - it makes us _less_ secure.
Did no-one think of merging the capabilities checks and the security subsystem
callbacks in some easy-to-use manner, which makes the default security policy
apparent at first sight?
This code should be written in a simpler form, something like:
retval = -EPERM;
if (!security_allow_task_fix_setuid(new, old)) {
new->suid = new->uid = uid;
if (uid != old->uid) {
retval = set_user(new);
if (retval < 0)
goto error;
}
} else if (uid != old->uid && uid != new->suid) {
goto error;
}
new->fsuid = new->euid = uid;
Where the default security_allow_task_fix_setuid() is basically a CAP_SETUID check -
and we know this from the 'security_allow_task_fix_setuid' name already.
This way all those stupid, passive security callbacks become _active participants of
the code_, and the code becomes more compact and easier to understand - and it
becomes harder to mess up both compatibility details and permission details.
[ And yes, i realize that this isnt a 100% replacement of the existing callback,
because some of the default logic cannot be turned off - but heck, that's a
feature not a bug! We dont want to allow security modules to make things _less_
secure, or break legacies, right? So they should be shaped as _additional_
restrictions on the coarse default semantics.
And dont get me started about the idiocy of LSM_SETID_ID. Why isnt that detail put
into the callback name? What's wrong with security_task_fix_setuid_id(new, old)? ]
Whoever allowed security modules to be added in their current form needs some
talking to.
Thanks,
Ingo