grsecurity forums

by **Hal9000** » Wed Dec 22, 2004 5:05 am

http://www.grsecurity.net/~spender/grse ... 1916.patch

how stable is that?

- hal

by **PaX Team** » Wed Dec 22, 2004 6:58 am

Hal9000 wrote:http://www.grsecurity.net/~spender/grsecurity-2.0.3-2.6.9-200412211916.patch

how stable is that?

- hal

follow the mailing list or the irc channel, and you'll know. mostly 'it works', but there're some reports that have to be investigated.

by **underattack** » Tue Dec 28, 2004 1:01 pm

As another datapoint, here is my experience. The system is essentially a Suse 9.2 install, Intel CPU, one serial ATA drive (Dell Poweredge 700).

I used the vanilla 2.6.9 kernel and the Dec. 23rd patch. reiserfsck dumps core after it checks the drive (looks like the check actually comes back clean).

Here is an strace if it helps:

(none):/etc/init.d/boot.d # strace fsck -a /
execve("/sbin/fsck", ["fsck", "-a", "/"], [/* 28 vars */]) = 0
uname({sys="Linux", node="(none)", ...}) = 0
brk(0) = 0x805cb70
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=37534, ...}) = 0
old_mmap(NULL, 37534, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7ff6000
close(3) = 0
open("/lib/libblkid.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\30\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=28974, ...}) = 0
old_mmap(NULL, 27084, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40018000
madvise(0x40018000, 27084, MADV_SEQUENTIAL|0x1) = 0
old_mmap(0x4001e000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5000) = 0x4001e000
close(3) = 0
open("/lib/libuuid.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\n\0\000"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=11509, ...}) = 0
old_mmap(NULL, 11388, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4001f000
madvise(0x4001f000, 11388, MADV_SEQUENTIAL|0x1) = 0
old_mmap(0x40021000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x40021000
close(3) = 0
open("/lib/tls/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0L\1\000"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1359489, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ff5000
old_mmap(NULL, 1137708, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40022000
madvise(0x40022000, 1137708, MADV_SEQUENTIAL|0x1) = 0
mprotect(0x40131000, 27692, PROT_NONE) = 0
old_mmap(0x40132000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x10f000) = 0x40132000
old_mmap(0x40136000, 7212, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40136000
close(3) = 0
mprotect(0x40132000, 4096, PROT_READ) = 0
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7ff5860, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, se0
munmap(0xb7ff6000, 37534) = 0
brk(0) = 0x805cb70
brk(0x807db70) = 0x807db70
brk(0x807e000) = 0x807e000
open("/dev/shm/tmp_blkid.tab", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=436, ...}) = 0
fcntl64(3, F_GETFL) = 0 (flags O_RDONLY)
fstat64(3, {st_mode=S_IFREG|0644, st_size=436, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fff000
_llseek(3, 0, [0], SEEK_CUR) = 0
read(3, "<device DEVNO=\"0x0801\" TIME=\"110"..., 4096) = 436
read(3, "", 4096) = 0
rt_sigaction(SIGINT, {0x8048fbgrsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by /sbin/fsck.reiserfs[0
0, [], SA_RESTORER, 0x40048de8}, NULL,

= 0
rt_sigaction(SIGTERM, {0x8048fb0, [], SA_RESTORER, 0x40048de8}, NULL,

= 0
write(1, "fsck 1.35 (28-Feb-2004)\n", 24fsck 1.35 (28-Feb-2004)
) = 24
open("/etc/fstab", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=759, ...}) = 0
mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fd5000
read(4, "/dev/sda4 / "..., 131072) = 759
read(4, "", 131072) = 0
close(4) = 0
munmap(0xb7fd5000, 131072) = 0
stat64("/sbin/fsck.reiserfs", {st_mode=S_IFREG|0755, st_size=295512, ...}) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7ff58a8) = 1897
time(NULL) = 1104253237
waitpid(-1, Reiserfs super block in block 16 on 0x804 of format 3.6 with standard journal
Blocks (total/free): 38766848/36592750 by 4096 bytes
Filesystem is clean
[{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV}], 0) = 1897
--- SIGCHLD (Child exited) @ 0 (0) ---
write(1, "Warning... fsck.reiserfs for dev"..., 69Warning... fsck.reiserfs for device /dev/sda4 exited with signal 11.
) = 69
write(1, "fsck.reiserfs /dev/sda4 failed ("..., 59fsck.reiserfs /dev/sda4 failed (status 0x8). Run manually!
) = 59
exit_group(8) = ?

by **Skywind** » Tue Dec 28, 2004 10:30 pm

If the "MAC system integration" option is default set to "direct"?
I remenber the grsec for 2.6.7 is default set to "none"?
some change happen?

Thx:)

by **PaX Team** » Wed Dec 29, 2004 5:39 am

underattack wrote:I used the vanilla 2.6.9 kernel and the Dec. 23rd patch. reiserfsck dumps core after it checks the drive (looks like the check actually comes back clean).

this should be fixed in PaX now, wait for spender to update grsec as well.

by **PaX Team** » Wed Dec 29, 2004 5:43 am

Skywind wrote:If the "MAC system integration" option is default set to "direct"?
I remenber the grsec for 2.6.7 is default set to "none"?
some change happen?

yes, it is 'direct' now (that is, if you want grsec to control the PaX flags, else you can use 'none' and rely on the ELF marks).

by **underattack** » Wed Dec 29, 2004 10:59 pm

PaX Team wrote:
underattack wrote:I used the vanilla 2.6.9 kernel and the Dec. 23rd patch. reiserfsck dumps core after it checks the drive (looks like the check actually comes back clean).
this should be fixed in PaX now, wait for spender to update grsec as well.

good to know. Can't wait :-)

by **spender** » Fri Dec 31, 2004 6:16 pm

A 2.6.10 patch is available at http://grsecurity.net/~spender

-Brad

by **forsaken** » Sat Jan 01, 2005 9:32 am

Happy new year everyone.

Spender I'm getting this error msg when im trying to compile 2.6.10 with the above patch:

grsecurity/grsec_chroot.c: In function `gr_pid_is_chrooted':
grsecurity/grsec_chroot.c:105: error: `TASK_ZOMBIE' undeclared (first use in this function)
grsecurity/grsec_chroot.c:105: error: (Each undeclared identifier is reported only once
grsecurity/grsec_chroot.c:105: error: for each function it appears in.)
make[1]: *** [grsecurity/grsec_chroot.o] Error 1

by **spender** » Sat Jan 01, 2005 9:48 am

I've fixed it, and am uploading a new patch now.

-Brad

by **ray** » Sat Jan 01, 2005 3:30 pm

Hi Brad, all,
Just wanna report that your second patch works for me (compiles OK).
After reboot could check also if it's working

Thanks for the great work.
PS:before that tried only with the PaX-patch, it compiled and worked too.
Happy NewYear.
Rumen

grsecurity forums

2.6.9-grsec

2.6.9-grsec

Re: 2.6.9-grsec

2.6.9 and reiserfsck

Re: 2.6.9 and reiserfsck

Re: 2.6.9 and reiserfsck