Archive
You are currently browsing the archives for the Linux Kernel category.
By cormander
So I setup new jobs in my Hudson server to track the “latest” kernel. It pulls in the latest changes, builds the kernel image, and with the -xenU ones, does a test boot. The current latest as of today is linux version 2.6.33.
It works on 32bit:
http://build.cormander.com/job/linux-2.6.latest-i686-vanilla-xenU/2/console
It does not work on 64bit:
http://build.cormander.com/job/linux-2.6.latest-x86_64-vanilla-xenU/2/console
But works on 64bit with grsecurity:
http://build.cormander.com/job/linux-2.6.latest-x86_64-grsec-xenU/1/console
Here is the output of the fail:
[ 0.370394] EXT3-fs (xvda2): warning: maximal mount count reached, running e2fsck is recommended
[ 0.372607] EXT3-fs (xvda2): using internal journal
[ 0.372632] EXT3-fs (xvda2): mounted filesystem with writeback data mode
[ 0.372670] VFS: Mounted root (ext3 filesystem) on device 202:2.
[ 0.372771] Freeing unused kernel memory: 668k freed
[ 0.373202] Write protecting the kernel read-only data: 10240k
[ 0.379890] Freeing unused kernel memory: 648k freed
[ 0.379910] BUG: unable to handle kernel paging request at ffff88000155e000
[ 0.379922] IP: [] free_init_pages+0xb1/0xda
[ 0.379939] PGD 1a2a067 PUD 1a2e067 PMD 1d38067 PTE 1000000155e025
[ 0.379955] Oops: 0003 [#1] SMP
[ 0.379965] last sysfs file:
[ 0.379973] CPU 0
[ 0.379984] Pid: 1, comm: swapper Not tainted 2.6.33 #1 /
[ 0.379992] RIP: e030:[] [] free_init_pages+0xb1/0xda
[ 0.380005] RSP: e02b:ffff880007c5fea0 EFLAGS: 00010286
[ 0.380005] RAX: 00000000cccccccc RBX: ffff88000155e000 RCX: 0000000000000400
[ 0.380005] RDX: ffffea000004ac91 RSI: 0000000000000000 RDI: ffff88000155e000
[ 0.380005] RBP: ffff880007c5fed0 R08: 0000000000000000 R09: ffff880007c08000
[ 0.380005] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000400
[ 0.380005] R13: ffff880001600000 R14: ffffea0000000000 R15: 00000000cccccccc
[ 0.380005] FS: 0000000000000000(0000) GS:ffff880001d45000(0000) knlGS:0000000000000000
[ 0.380005] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 0.380005] CR2: ffff88000155e000 CR3: 0000000001a29000 CR4: 0000000000000660
[ 0.380005] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 0.380005] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000000
[ 0.380005] Process swapper (pid: 1, threadinfo ffff880007c5e000, task ffff880007c60000)
[ 0.380005] Stack:
[ 0.380005] 0000000000000000 6db6db6db6db6db7 0000000000000400 ffff880000000000
[ 0.380005] <0> ffffffff81600000 0000000000000000 ffff880007c5ff00 ffffffff8102c9c4
[ 0.380005] <0> ffffffff81b9d960 0000000000000040 ffffffff81afbc60 ffffffff81afbc68
[ 0.380005] Call Trace:
[ 0.380005] [] mark_rodata_ro+0xe0/0x146
[ 0.380005] [] init_post+0x2b/0x19d
[ 0.380005] [] kernel_init+0x19f/0x1aa
[ 0.380005] [] kernel_thread_helper+0x4/0x10
[ 0.380005] [] ? int_ret_from_sys_call+0x7/0x1b
[ 0.380005] [] ? retint_restore_args+0x5/0x6
[ 0.380005] [] ? kernel_thread_helper+0x0/0x10
[ 0.380005] Code: 89 df e8 27 49 00 00 48 c1 e8 0c 48 89 df 4c 89 e1 48 6b c0 38 48 81 e7 00 f0 ff ff 31 f6 4c 01 f0 c7 40 08 01 00 00 00 44 89 f8 ab 48 89 df 48 81 c3 00 10 00 00 e8 93 a3 08 00 48 ff 05 33
[ 0.380005] RIP [] free_init_pages+0xb1/0xda
[ 0.380005] RSP
[ 0.380005] CR2: ffff88000155e000
[ 0.380005] ---[ end trace 39c6a8b0e7165bad ]---
[ 0.394371] swapper used greatest stack depth: 5160 bytes left
[ 0.394385] Kernel panic - not syncing: Attempted to kill init!
[ 0.394395] Pid: 1, comm: swapper Tainted: G D 2.6.33 #1
[ 0.394403] Call Trace:
[ 0.394413] [] panic+0x75/0x137
[ 0.394425] [] ? exit_ptrace+0xb1/0x131
[ 0.394436] [] do_exit+0x77/0x777
[ 0.394446] [] ? xen_restore_fl_direct_end+0x0/0x1
[ 0.394458] [] ? kmsg_dump+0x126/0x140
[ 0.394470] [] ? __acpi_nmi_disable+0x14/0x1d
[ 0.394480] [] oops_end+0xb9/0xc1
[ 0.394490] [] no_context+0x1f3/0x202
[ 0.394500] [] ? __acpi_nmi_disable+0x14/0x1d
[ 0.394511] [] ? atomic_notifier_call_chain+0x13/0x15
[ 0.394522] [] __bad_area_nosemaphore+0x1c0/0x1e6
[ 0.394533] [] ? xen_force_evtchn_callback+0xd/0xf
[ 0.394544] [] ? check_events+0x12/0x20
[ 0.394554] [] ? xen_force_evtchn_callback+0xd/0xf
[ 0.395349] [] ? check_events+0x12/0x20
[ 0.395349] [] ? __raw_callee_save_xen_pmd_val+0x11/0x1e
[ 0.395349] [] bad_area_nosemaphore+0xe/0x10
[ 0.395349] [] do_page_fault+0x1a0/0x2dd
[ 0.395349] [] page_fault+0x25/0x30
[ 0.395349] [] ? free_init_pages+0xb1/0xda
[ 0.395349] [] mark_rodata_ro+0xe0/0x146
[ 0.395349] [] init_post+0x2b/0x19d
[ 0.395349] [] kernel_init+0x19f/0x1aa
[ 0.395349] [] kernel_thread_helper+0x4/0x10
[ 0.395349] [] ? int_ret_from_sys_call+0x7/0x1b
[ 0.395349] [] ? retint_restore_args+0x5/0x6
[ 0.395349] [] ? kernel_thread_helper+0x0/0x10
A little digging and I unset CONFIG_DEBUG_RODATA in the vanilla configuration (it gets unset by the grsecurity patch) and rebuilt it. It works! Okay, so we have a regression in xen pv_ops when RODATA is enabled, because linux-2.6.32.9 (and other 2.6.32 kernels before it) boot just fine with DEBUG_RODATA enabled.
I don’t even know who to report this to. Then again, I don’t use vanilla xen domU kernels.. I just use them as a reference point when testing vanilla vs. grsecurity. I only actually use the grsecurity xen domU kernels, and those work. So I guess I’ll just sit back and wait for someone else to notice, and fix it.
By cormander
I just created a new tag: “moment of insanity”. I plan to have many of these in my lifetime.
This is one of them. The other night at about 11pm I thought:
“Hey, there isn’t a reason why non-root users should know what the kernel version is, so why not restrict it?”
So I wrote the following patch and sent it over to the grsecurity project:
diff --git a/arch/x86/kernel/sys_x86_64.c b/arch/x86/kernel/sys_x86_64.c
index eedcb8a..338ceda 100644
--- a/arch/x86/kernel/sys_x86_64.c
+++ b/arch/x86/kernel/sys_x86_64.c
@@ -230,10 +230,19 @@ bottomup:
SYSCALL_DEFINE1(uname, struct new_utsname __user *, name)
{
int err;
+#ifdef CONFIG_GRKERNSEC_HIDE_VERSION
+ const struct cred *cred = current_cred();
+#endif
+
down_read(&uts_sem);
err = copy_to_user(name, utsname(), sizeof(*name));
up_read(&uts_sem);
if (personality(current->personality) == PER_LINUX32)
err |= copy_to_user(&name->machine, "i686", 5);
+#ifdef CONFIG_GRKERNSEC_HIDE_VERSION
+ if (cred->uid != 0)
+ err |= copy_to_user(&name->release, "", 1);
+#endif
+
return err ? -EFAULT : 0;
}
diff --git a/grsecurity/Kconfig b/grsecurity/Kconfig
index f32b4f0..417e256 100644
--- a/grsecurity/Kconfig
+++ b/grsecurity/Kconfig
@@ -345,6 +345,17 @@ config GRKERNSEC_HIDESYM
useful protection against local kernel exploitation of overflows
and arbitrary read/write vulnerabilities.
+config GRKERNSEC_HIDE_VERSION
+ bool "Hide kernel version"
+ help
+ If you say Y here, calls to the uname syscall as a non-root user will
+ lack the kernel's version information. Note that to completly hide
+ the version of the kernel, other areas of the system must also be
+ hardened such as read access to the /boot/ and /lib/modules/
+ directories, the /proc/version file, and read access to the system's
+ package database (if you installed the grsecurity kernel via a pre-
+ compiled package).
+
endmenu
menu "Role Based Access Control Options"
depends on GRKERNSEC
diff --git a/kernel/sys.c b/kernel/sys.c
index 7837305..ee5e180 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1154,10 +1154,17 @@ DECLARE_RWSEM(uts_sem);
SYSCALL_DEFINE1(newuname, struct new_utsname __user *, name)
{
int errno = 0;
+#ifdef CONFIG_GRKERNSEC_HIDE_VERSION
+ const struct cred *cred = current_cred();
+#endif
down_read(&uts_sem);
if (copy_to_user(name, utsname(), sizeof *name))
errno = -EFAULT;
+#ifdef CONFIG_GRKERNSEC_HIDE_VERSION
+ if (cred->uid != 0)
+ errno |= copy_to_user(&name->release, "", 1);
+#endif
up_read(&uts_sem);
return errno;
}
I knew the patch wasn’t complete, but I wanted to see what was said.
Needless to say, it was sent back with the “useless” label all over it. Bottom line, there are other ways to determine kernel version if you have a local user (what syscalls exist or not, for example). I knew that was still possible; the idea in my (sleep-deprived) head was it’ll prevent script kiddies from knowing the kernel version.
But that doesn’t stop them from trying every vulnerability in the book anyway.
By cormander
The past week I’ve been talking about Hudson, and not just here. Quite frankly I think some of my buddies are sick of me talking about it. For this (and other) reasons, I exposed the build system at this URL:
http://build.cormander.com/
I granted anonymous view access to most of it. I currently have ravencore in there, and my grsecurity stack setup in there and building successfully. Pretty soon I’ll be putting rootsh and other projects I manage in there, as well as things like python26 for CentOS, Xen 3.4 for CentOS, and any other thing that comes to mind that I have built and made use of.
And as far as this saving my world goes, it’s because it reduces the amount of effort I have to put into this stuff, which means I can do more of it.
By cormander
So I decided that since Hudson is so cool that I’d try to build something as big as the linux kernel inside it. I put the rpmbuild command for my grsecurity kernel inside and watched my builds fail until I got it just right. I ended up with a small git repo to revision control the spec file, kernel config, and a new Makefile to tie it all together.
Long story short, I now have automated builds of my spec file which is now capable of building the grsecurity kernel, the PaX kernel, and the vanilla kernel, all depending on how you call it: make grsec, make pax, and make vanilla respectively. I have each setup with both 32bit and 64bit builds, each takes two hours to do. So I just commit a change to apply a new grescurity or kernel patch, and 12 hours later I have all the RPMs fresh out of hudson and I don’t have to so much as bat an eyelash for it. Unless, of course, a build fails. If one fails, they’re all liable to fail for the same reason. So I’m gonna need some more build slaves so it doesn’t take as long in the future.
I know, I know, I’m not “using hudson how it is intended” because hudson itself is a build system, and rpmbuild is a seperate build system, so I’m having a build system calling a build system so each build has to “take it from the top”. But I don’t care about what it was designed to do, I care about what it can do.
And it rocks.
By cormander
2.6.27.1 came out today, with only one patch:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.27.y.git;a=commitdiff;h=d23d43386311fde5f11e06c16d4185e94a8d6d06
It’s quite small, see below:
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index 263e9e6..aa53fdd 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -103,7 +103,8 @@ config CONTEXT_SWITCH_TRACER
all switching of tasks.
config DYNAMIC_FTRACE
- bool "enable/disable ftrace tracepoints dynamically"
+ bool "enable/disable ftrace tracepoints dynamically (BROKEN)"
+ depends on BROKEN
depends on FTRACE
depends on HAVE_DYNAMIC_FTRACE
default y
As I recall this was supposed to be fixed for 2.6.27. Now they’re just turning it off again?
Well, glad they did come out and turn it off. But still, this is a big fail!
By cormander
For those of you that have been wondering, I’ve been spending a lot of my free time working with my good friend Tim Post working on a project called gridnix.
I’ll mostly be doing userspace applications and packaging, but so far my main contribution has been the kernel for the OS. I just recently posted all my patches to the kernel to a git tree:
http://git.ravencore.com/?p=kernel/linux-2.6.24.7-gridnix.git;a=summary
The tree is lacking config and build scripts at the moment, but it’ll build just fine as-is. A little later we’ll be adding those scripts to easilly build different kernel variants such as a xen dom0 kernel or a full fledged grsecurity kernel.
By cormander
Well, since the NTFS kernel module is probably more sought after in an enterprise kernel more then the reiserfs module, I decided to also make an RPM for the nfts kernel module for the centos5 kernel. See the link below:
http://download.ravencore.com/misc/kernel-module-ntfs-2.6.18-92.1.10.el5.src.rpm
And, if I feel like it, I might start to maintain this stuff in a yum repo for i386 and x86_64. If that happens, I’ll even go ahead and throw a depmod command in a %post script of the RPM for you all so you can modprobe it, instead of having to insmod it.
By cormander
I realize that the centosplus kernel has reiserfs support enabled in it, but since EMCpower doesn’t support even the centosplus kernel, I had to take matters into my own hands.
Since I don’t want to compile the module on every freaking node by hand, I decided to make a “proper” rpm for it. See the source RPM at the link below. You’ll need the kernel-devel package in order to build it.
http://download.ravencore.com/misc/kernel-module-reiserfs-2.6.18-92.1.10.el5.src.rpm
rpmbuild --rebuild --target `uname -m` kernel-module-reiserfs-2.6.18-92.1.10.el5.src.rpm
If you’re using the xen kernel, you can build the module for the xen kernel by passing “–with xen” to the rpmbuild command, and you’ll need the kernel-xen-devel package installed.
It basically makes a copy of your kernel-devel, adds the reiserfs source to it (as extracted from the source of that kernel), patches the config to enable reiserfs, and builds it.
Now obviously there will eventually be a newer kernel then 2.6.18-92.1.10.el5, at which point just modify the version string in the “Release” line of the spec file, and rebuild it, and it should still work.
By cormander
So I was configuring a server today which was running my kernel-grsec-2.6.24.7-200805121951.7.i686.rpm RPM, and I tried to start nfs to mount a share. I was (not) pleasantly surprised to see a nice big kernel OOPs spit onto my screen. The system didn’t crash, but the nfs process segfaulted (of course) and I was left there without my share mounted. Damn.
So I load my nopax kernel, then my chocolate kernel, same thing on those. By this time I was freezing my butt off because I didn’t have a jacket, the data center is cold, and this Dell 2850 takes so freaking long to boot, before it even gets to the grub prompt (even when you skip the mem check). Too bad the Dell DRAC sucks, I would have rather remote consoled this.
Anyway, I finally boot with the vanilla kernel, and no OOPs, my nfs share gets mounted and works. So I go and find one of my non-chocolate grsecurity kernels and, yep, that boots up with no OOPs on nfs either. So, it’s one (or more) of the thousands of patches that I put into this kernel that is mucking things up.
Well, I have to say that the whole automated patch pull from the upstream kernel git was a neat project, taught me a lot. I knew in the back of my mind the whole time I would eventually run into a problem like this and I’d then have to scratch the whole thing. After all, don’t patch code when you don’t _really_ know what the hell that patch is doing, and I had thousands of them. Literally.
With my wife not being pregnant any more and things settling down at work as well, I’ll push out my next kernel update pretty soon with a few more CVE patches, and all that other stuff removed. No more chocolate kernel, no more NFS oops, and an experience behind me.
By cormander
So I try to boot my 2.6.25.7 kernel that I built from last night, and it panics on my CentOS 5 box (but not my fedora core 9 box). In the output just before the panic, the sata and such drivers are loaded but the initrd is unable to see the drive which I found to be very odd.
After a conversation with Scott Shinn he points me in the direction of SYSFS changes in the 2.6.25 kernel. I hacked the fedora core 9 initrd to boot on the CentOS 5 machine, and it booted normally. Long story short, I recompiled the kernel with this option enabled in the config:
CONFIG_SYSFS_DEPRECATED_V2=y
Turns out that things like udev and nash croak on the latest kernel if they aren’t the latest version of themselves (which they obviously aren’t on an enterprise os). This config option turns on the “deprecated” sysfs system calls and fixes the issue. Thankfully the kernel with this option on still seems to work when booting a fedora core 9 machine.
This particular issue is a pretty good reason to continue to stick with 2.6.24.7 for my “stable” kernel – I’d hate to have to use deprecated systemcalls in a later kernel, they’re no longer maintained, not guaranteed to work, and once they start to conflict with other kernel internals, they are removed altogether.
This isn’t the first time I’ve had to deal with something like this when upgrading the linux kernel to a whole new version tree, hense the title of this article being “wack-a-mole”. You narrow in on one problem and smack it, and pretty soon you find yourself with two or three more sticking back up at you in other locations that you have to hunt down as fast as you can.
