Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Hardened

Security Level: high/server/workstation/virtualization

  

 
First page Previous page 1 2 Next page Last page  View All Gentoo hardened RSS feed   Index | Next | Previous | View Threaded


powerman at powerman

Jan 27, 2012, 5:26 AM

Post #1 of 27 (923 views)
Permalink
Security Level: high/server/workstation/virtualization
Hi!

If you ever wonder how exactly differs predefined security levels, you'll
find this information here. :) I've compared them, plus I did some
benchmarking (Core2Duo E6600, 32bit OS, hardened-sources-3.1.5,
single-user mode, kernel compile with -j3 as average user+sys time in 3 tests).

This information shouldn't surprise hardened developers, but if there are
some bugs with these levels then chances are you'll notice them now.

I didn't tested low and medium levels because I don't think they have any
real use.

First table: differences between these security levels.
"-" mean this level switch off that option
"+" mean this level switch on that option
" " mean this level doesn't change that option

high server ws virt
CONFIG_X86_32_LAZY_GS - -
CONFIG_CC_STACKPROTECTOR - -
CONFIG_GRKERNSEC_IO +
CONFIG_GRKERNSEC_KERN_LOCKOUT +
CONFIG_GRKERNSEC_PROC_ADD + +
CONFIG_GRKERNSEC_SYSFS_RESTRICT +
CONFIG_GRKERNSEC_PROC_IPADDR + + +
CONFIG_GRKERNSEC_RWXMAP_LOG + + +
CONFIG_GRKERNSEC_SYSCTL + + +
CONFIG_GRKERNSEC_SYSCTL_ON + + +
CONFIG_PAX_PER_CPU_PGD + + + -
CONFIG_PAX_ELFRELOCS +
CONFIG_PAX_KERNEXEC + + + -
CONFIG_PAX_KERNEXEC_MODULE_TEXT 4 4 4 -
CONFIG_PAX_MEMORY_SANITIZE + + +
CONFIG_PAX_MEMORY_UDEREF + + -

As you can see, if you switch between several levels you may end with
different options on same level - for example, switching from server to
workstation result in UDEREF on, while switching from virtualization to
workstation result in UDEREF off. That's correct, but you should keep this
in mind and re-check configuration after switching security level.

Next, list of options which doesn't changed by any of these security
levels, i.e. they are left completely up to user's choice. I'll show them
both in CONFIG and menuconfig formats:

CONFIG_GRKERNSEC_ACL_HIDEKERN
CONFIG_GRKERNSEC_EXECLOG
CONFIG_GRKERNSEC_CHROOT_EXECLOG
CONFIG_GRKERNSEC_AUDIT_PTRACE
CONFIG_GRKERNSEC_AUDIT_CHDIR
CONFIG_GRKERNSEC_AUDIT_TEXTREL
CONFIG_GRKERNSEC_BLACKHOLE
CONFIG_PAX_EMUTRAMP
CONFIG_PAX_MPROTECT_COMPAT
CONFIG_PAX_MEMORY_STACKLEAK

Grsecurity --->
[*] Grsecurity
Role Based Access Control Options --->
[ ] Hide kernel processes
Kernel Auditing --->
[ ] Exec logging
[ ] Log execs within chroot
[ ] Ptrace logging
[ ] Chdir logging
[ ] ELF text relocations logging (READ HELP)
Network Protections --->
[ ] TCP/UDP blackhole and LAST_ACK DoS prevention
PaX --->
[*] Enable various PaX features
Non-executable pages --->
[ ] Emulate trampolines
[ ] Use legacy/compat protection demoting (read help)
Miscellaneous hardening features --->
[ ] Sanitize kernel stack

All other GrSecurity/PaX options are switched on by all these security levels.

Now, about benchmarking. I've enabled as much options as possible on
workstation: server security level PLUS all good optional options MINUS
CONFIG_GRKERNSEC_IO (for Xorg). And compared it to completely non-hardened
environment (kernel with GrSecurity/PaX switched off and vanilla gcc).

This way hardened was ~5% slower.
Without CONFIG_PAX_MEMORY_STACKLEAK it become ~3% slower.
Without CONFIG_PAX_MEMORY_STACKLEAK and CONFIG_PAX_MEMORY_SANITIZE - ~1% slower.

As for me, spending ~1% performance for ~all hardened is good trade off,
but spending 4% more for protection against leaking information in freed
memory is too much for workstation (and for most servers too), so I
recommend to change workstation security level to not enable
CONFIG_PAX_MEMORY_SANITIZE by default.

--
WBR, Alex.


ma1l1ists at yahoo

Jan 27, 2012, 8:25 AM

Post #2 of 27 (889 views)
Permalink
Re: Security Level: high/server/workstation/virtualization [In reply to]
On Fri, 27 Jan 2012 15:26:26 +0200
Alex Efros wrote:

Thanks for the info. In a discussion about malloc flags, it was
mentioned on the OpenBSD list that clearing the memory
immediately brought little in security as it would be cleared before
re-use and if anything could increase the chances of an attacker
writing to areas that he wanted to.

> Core2Duo

I don't know the details but according to OpenBSDs Theo, the Core2Duo
had some major design flaws that intel couldn't fix with microcode with
some security implications.


p.labushev at gmail

Jan 27, 2012, 12:11 PM

Post #3 of 27 (890 views)
Permalink
Re: Security Level: high/server/workstation/virtualization [In reply to]
27.01.2012 21:26, Alex Efros wrote:

> As for me, spending ~1% performance for ~all hardened is good trade off,
> but spending 4% more for protection against leaking information in freed
> memory is too much for workstation (and for most servers too), so I
> recommend to change workstation security level to not enable
> CONFIG_PAX_MEMORY_SANITIZE by default.

Isn't sacrificing 4% of performance to prevent attackers from circumventing
all the other measures like KERNEXEC and UDEREF with an arbitrary write and
a kernel memory leak a fair deal? I think it is, often than not.

If you need some profiles to favour small performance gains over more secure
defaults, then maybe you should propose additional profiles to accomplish
exactly that, and clearly state that 4% gain in the config help.
Attachments: signature.asc (0.82 KB)


powerman at powerman

Jan 27, 2012, 12:19 PM

Post #4 of 27 (892 views)
Permalink
Re: Security Level: high/server/workstation/virtualization [In reply to]
Hi!

Two small notes related to security level defaults:

1) On my system vmware reboot host OS when starting guest OS if any one
(or both) of these are enabled:

CONFIG_PAX_KERNEXEC (enabled by default on workstation security level)
CONFIG_PAX_MEMORY_UDEREF

2) When wireshark started by non-root user this option kill all my
processes (https://bugs.gentoo.org/show_bug.cgi?id=379369):

CONFIG_GRKERNSEC_BRUTE (enabled by default on all security levels)

--
WBR, Alex.


pageexec at freemail

Jan 27, 2012, 12:34 PM

Post #5 of 27 (903 views)
Permalink
Re: Security Level: high/server/workstation/virtualization [In reply to]
On 27 Jan 2012 at 16:25, Kevin Chadwick wrote:

> Thanks for the info. In a discussion about malloc flags, it was
> mentioned on the OpenBSD list that clearing the memory
> immediately brought little in security as it would be cleared before
> re-use and if anything could increase the chances of an attacker
> writing to areas that he wanted to.

the SANITIZE feature of PaX doesn't clear userland memory, it clears kernel pages
when they're freed back to the lowest level kernel memory allocator. it is meant
to reduce the amount of information that can be leaked by kernel bugs from kernel
space to userland. if these pages were cleared on allocation only (as is the case
without SANITIZE) then they'd be subject to said infoleaking bugs while sitting
on the free page list.

also as an optimization these early-cleared pages are not cleared again when the kernel
metes them out to the next user.

> > Core2Duo
>
> I don't know the details but according to OpenBSDs Theo, the Core2Duo
> had some major design flaws that intel couldn't fix with microcode with
> some security implications.

yeah, Theo for president! of the lunatic asylum.


pageexec at freemail

Jan 27, 2012, 12:40 PM

Post #6 of 27 (895 views)
Permalink
Re: Security Level: high/server/workstation/virtualization [In reply to]
On 27 Jan 2012 at 22:19, Alex Efros wrote:

> Hi!
>
> Two small notes related to security level defaults:
>
> 1) On my system vmware reboot host OS when starting guest OS if any one
> (or both) of these are enabled:
>
> CONFIG_PAX_KERNEXEC (enabled by default on workstation security level)
> CONFIG_PAX_MEMORY_UDEREF

vmware needs patching to work with these features, i think there's a bug or two
open about this in the gentoo bugzilla already.

> 2) When wireshark started by non-root user this option kill all my
> processes (https://bugs.gentoo.org/show_bug.cgi?id=379369):

can you generate a coredump and see what the backtrace shows?


prometheanfire at gentoo

Jan 27, 2012, 1:14 PM

Post #7 of 27 (889 views)
Permalink
Re: Security Level: high/server/workstation/virtualization [In reply to]
On Fri, 27 Jan 2012 22:19:42 +0200
Alex Efros <powerman [at] powerman> wrote:

> Hi!
>
> Two small notes related to security level defaults:
>
> 1) On my system vmware reboot host OS when starting guest OS if any
> one (or both) of these are enabled:
>
> CONFIG_PAX_KERNEXEC (enabled by default on workstation security
> level) CONFIG_PAX_MEMORY_UDEREF
>
> 2) When wireshark started by non-root user this option kill all my
> processes (https://bugs.gentoo.org/show_bug.cgi?id=379369):
>
> CONFIG_GRKERNSEC_BRUTE (enabled by default on all security levels)
>

You should be using the virt profile.

--
Matthew Thode (prometheanfire)
Attachments: signature.asc (0.82 KB)


powerman at powerman

Jan 27, 2012, 1:20 PM

Post #8 of 27 (890 views)
Permalink
Re: Security Level: high/server/workstation/virtualization [In reply to]
Hi!

On Fri, Jan 27, 2012 at 03:14:12PM -0600, Matthew Thode wrote:
> You should be using the virt profile.

Why? As far as I understand, virt profile is for guest OS, not host OS.

--
WBR, Alex.


klondike at gentoo

Jan 27, 2012, 1:28 PM

Post #9 of 27 (894 views)
Permalink
Re: Security Level: high/server/workstation/virtualization [In reply to]
El 27/01/12 22:20, Alex Efros escribi:
> Hi!
>
> On Fri, Jan 27, 2012 at 03:14:12PM -0600, Matthew Thode wrote:
>> You should be using the virt profile.
> Why? As far as I understand, virt profile is for guest OS, not host OS.
Virt profile is for both of them, that's why it is called virt. Anyway
and since some of the issues regarding hardening and virt are becoming
solved on some hardwares as time passes some of the settings on virt are
tunable so you can try enabling them first.
Attachments: signature.asc (0.26 KB)


powerman at powerman

Jan 27, 2012, 3:02 PM

Post #10 of 27 (935 views)
Permalink
Re: Security Level: high/server/workstation/virtualization [In reply to]
Hi!

On Fri, Jan 27, 2012 at 10:40:43PM +0200, pageexec [at] freemail wrote:
> > 2) When wireshark started by non-root user this option kill all my
> > processes (https://bugs.gentoo.org/show_bug.cgi?id=379369):
> can you generate a coredump and see what the backtrace shows?

Actually I can't get core. :-/ Look:

I've re-emerged wireshark using this:

# CFLAGS="-march=prescott -O1 -pipe -ggdb" \
FEATURES="userpriv usersandbox userfetch parallel-fetch nostrip" \
emerge wireshark

Now:

$ sudo zgrep ELF_CORE /proc/config.gz
CONFIG_ELF_CORE=y
$ cat /proc/sys/kernel/core_pattern
core
$ grep core /etc/security/limits.conf | grep -v '^#'
* soft core unlimited
$ cat /etc/limits.conf
* C20480
$ ulimit -c unlimited
$ ulimit -c
unlimited
$ dumpcap
Segmentation fault
$ ls -l core
ls: cannot access core: No such file or directory

But under strace core generated ok:

$ strace dumpcap
...
socket(PF_PACKET, SOCK_RAW, 768) = -1 EPERM (Operation not permitted)
socket(PF_INET, SOCK_PACKET, 0x300 /* IPPROTO_??? */) = -1 EPERM (Operation not permitted)
open("/sys/class/net", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 EACCES (Permission denied)
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
--- {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x4} (Segmentation fault) ---
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault (core dumped)

$ ls -l core
-rw------- 1 powerman users 446464 Jan 28 00:59 core

$ gdb
(gdb) core core
[New LWP 26950]
Core was generated by `strace dumpcap'.
Program terminated with signal 11, Segmentation fault.
#0 0xa6dda422 in __kernel_vsyscall ()
(gdb) bt
#0 0xa6dda422 in __kernel_vsyscall ()
#1 0xa6c946a6 in ?? ()
#2 0x1f69cd64 in ?? ()
#3 0x1f663179 in ?? ()
#4 0x0000000b in ?? ()
#5 0x00000000 in ?? ()
(gdb)

Here is another way:

$ gdb dumpcap
(gdb) run
Starting program: /usr/bin/dumpcap

Program received signal SIGSEGV, Segmentation fault.
0xab94e152 in ?? ()
(gdb) bt
#0 0xab94e152 in ?? ()
#1 0xaba4c197 in ?? ()
#2 0xaba4fd99 in ?? ()
#3 0xaba51e37 in ?? ()
#4 0x16f4269d in get_interface_list_findalldevs (err=0xbdaff4a8, err_str=0xbdaff4a4)
at capture-pcap-util.c:174
#5 0x16f409c0 in get_interface_list (err=0xbdaff4a8, err_str=0xbdaff4a4)
at capture-pcap-util-unix.c:110
#6 0x16f469d2 in capture_interface_list (err=0xbdaff4a8, err_str=0xbdaff4a4) at dumpcap.c:797
#7 0x16f42345 in capture_opts_trim_iface (capture_opts=0x16f4e060, capture_device=0x0)
at capture_opts.c:770
#8 0x16f476cd in main (argc=<optimized out>, argv=<optimized out>) at dumpcap.c:3850
(gdb)

Is this enough, or I can do more?

--
WBR, Alex.


powerman at powerman

Jan 27, 2012, 3:07 PM

Post #11 of 27 (890 views)
Permalink
Re: Security Level: high/server/workstation/virtualization [In reply to]
Hi!

On Sat, Jan 28, 2012 at 01:02:40AM +0200, Alex Efros wrote:
> Is this enough, or I can do more?

Ok, this one is better:

# paxctl -mr /usr/bin/dumpcap
$ gdb dumpcap
(gdb) run
Starting program: /usr/bin/dumpcap
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0xb7658152 in readdir64 () from /lib/libc.so.6
(gdb) bt
#0 0xb7658152 in readdir64 () from /lib/libc.so.6
#1 0xb7756197 in ?? () from /usr/lib/libpcap.so.1
#2 0xb7759d99 in pcap_platform_finddevs () from /usr/lib/libpcap.so.1
#3 0xb775be37 in pcap_findalldevs () from /usr/lib/libpcap.so.1
#4 0xb78e369d in get_interface_list_findalldevs (err=0xbfffe798, err_str=0xbfffe794)
at capture-pcap-util.c:174
#5 0xb78e19c0 in get_interface_list (err=0xbfffe798, err_str=0xbfffe794)
at capture-pcap-util-unix.c:110
#6 0xb78e79d2 in capture_interface_list (err=0xbfffe798, err_str=0xbfffe794) at dumpcap.c:797
#7 0xb78e3345 in capture_opts_trim_iface (capture_opts=0xb78ef060, capture_device=0x0)
at capture_opts.c:770
#8 0xb78e86cd in main (argc=<optimized out>, argv=<optimized out>) at dumpcap.c:3850
(gdb)

--
WBR, Alex.


pageexec at freemail

Jan 27, 2012, 3:07 PM

Post #12 of 27 (890 views)
Permalink
Re: Security Level: high/server/workstation/virtualization [In reply to]
On 28 Jan 2012 at 1:15, Alex Efros wrote:

> $ gdb dumpcap --batch --quiet -ex 'run' -ex 'thread apply all bt full' -ex quit
>
> What's next? Recompile glibc with same CFLAGS/FEATURES and try again?

having debug info for glibc won't hurt for sure ;).

> Program received signal SIGSEGV, Segmentation fault.
> 0xb75fd152 in readdir64 () from /lib/libc.so.6

x/16i $pc
x/16x $sp

and based on the disasm i'll need more info later.


powerman at powerman

Jan 27, 2012, 3:15 PM

Post #13 of 27 (899 views)
Permalink
Re: Security Level: high/server/workstation/virtualization [In reply to]
Hi!

I've re-emerged libpcap and run this:

$ gdb dumpcap --batch --quiet -ex 'run' -ex 'thread apply all bt full' -ex quit

What's next? Recompile glibc with same CFLAGS/FEATURES and try again?


[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0xb75fd152 in readdir64 () from /lib/libc.so.6

Thread 1 (Thread 0xb754f6c0 (LWP 829)):
#0 0xb75fd152 in readdir64 () from /lib/libc.so.6
No symbol table info available.
#1 0xb76fb7ea in scan_sys_class_net (devlistp=0xbfffe758, errbuf=0xbfffe7ac "tun0: You don't have permission to capture on that device (socket: Operation not permitted)") at ./pcap-linux.c:1832
sys_class_net_d = 0x0
fd = 9
ent = <optimized out>
p = <optimized out>
name = "\261~d\267\234\344\377\277.\204q\267\304\345\377\277\254\347\377\277\000\000\000\000\234\344\377\277\377\000\000\000\001\200\255\373\254\347\377\277\254\347\377\277\254\347\377\277\254\347\377\277\a\350\377\277\253\350\377\277\254\347\377\277\253\350\377\277", '\000' <repeats 20 times>, "\030\023\000\000\004\000\000\000T\256k\267\000\000\000\000\000\000\000\000ٜ\211\267\335\022\253U\230b\211\267Ԝ\211\267\000\000\000\000`\234r\267\020\200\211\267\220h]\267h\345\377\277\211%p\267\020\200\211\267\377\377\000\000\325<^\267(Pp\267v\000\000\000\271~i\267āi\267\270\303k\267\000\251k\267\000\000\000\000Ԝ\211\267\335\022\253U`\234r\267\020\200\211\267\300\306k\267\320\020\000\000\200\303k\267T\256k\267\200\303k\267Ԝ\211\267x\345\377\277\243\235]\267\250\345\377\277\335\022\253U`\234r\267\020\200\211\267\250\345\377\277Z)p\267\020\200\211\267Ԝ\211\267\250\345\377\277\330}d\267\254\347\377\277\000\001\000\000\001\000\000\000\335\022\253U`\234r\267\020\200\211\267\b\346\377\277A+p\267\020\200\211\267\000\001\000\000\001\000\000\000\377\377\377\377.\204q\267Ԝ\211\267\370\177q\267\064\201\211\267\000\000\000\000\000\000\000\000D\000\000\000\254\347\377\277T\256k\267\000\000\000\000\331Be\267\335\022\253U\020Ee\267\274\346\377\277\034\223\211\267`\234r\267\000\000\000\000Ԝ\211\267x\346\377\277\341-p\267Ԝ\211\267D\000\000\000\364W]\267\000\000\000\000\254\347\377\277\005\000\000\000\214\265i\267\234~i\267\271~i\267\220\201i\267\254\303k\267"...
q = <optimized out>
ifrflags = {ifr_ifrn = {ifrn_name = "T\256k\267<\345\377\277\254\347\377\277\210\345\377\277"}, ifr_ifru = {ifru_addr = {sa_family = 32433, sa_data = "d\267<\345\377\277\254\347\377\277\210\345\377\277"}, ifru_dstaddr = {sa_family = 32433, sa_data = "d\267<\345\377\277\254\347\377\277\210\345\377\277"}, ifru_broadaddr = {sa_family = 32433, sa_data = "d\267<\345\377\277\254\347\377\277\210\345\377\277"}, ifru_netmask = {sa_family = 32433, sa_data = "d\267<\345\377\277\254\347\377\277\210\345\377\277"}, ifru_hwaddr = {sa_family = 32433, sa_data = "d\267<\345\377\277\254\347\377\277\210\345\377\277"}, ifru_flags = 32433, ifru_ivalue = -1218150735, ifru_mtu = -1218150735, ifru_map = {mem_start = 3076816561, mem_end = 3221218620, base_addr = 59308, irq = 255 '\377', dma = 191 '\277', port = 136 '\210'}, ifru_slave = "\261~d\267<\345\377\277\254\347\377\277\210\345\377\277", ifru_newname = "\261~d\267<\345\377\277\254\347\377\277\210\345\377\277", ifru_data = 0xb7647eb1, ifru_settings = {type = 3076816561, size = 3221218620, ifs_ifsu = {raw_hdlc = 0xbfffe7ac, cisco = 0xbfffe7ac, fr = 0xbfffe7ac, fr_pvc = 0xbfffe7ac, fr_pvc_info = 0xbfffe7ac, sync = 0xbfffe7ac, te1 = 0xbfffe7ac}}}}
ret = 1
#2 0xb76fefff in pcap_platform_finddevs (alldevsp=0xbfffe758, errbuf=0xbfffe7ac "tun0: You don't have permission to capture on that device (socket: Operation not permitted)") at ./pcap-linux.c:2081
ret = <optimized out>
#3 0xb7701232 in pcap_findalldevs (alldevsp=0xbfffe7a8, errbuf=0xbfffe7ac "tun0: You don't have permission to capture on that device (socket: Operation not permitted)") at ./fad-getad.c:275
devlist = 0x0
ifap = 0xb7899328
ifa = 0x0
addr = <optimized out>
netmask = <optimized out>
broadaddr = <optimized out>
dstaddr = <optimized out>
addr_size = <optimized out>
broadaddr_size = <optimized out>
dstaddr_size = <optimized out>
ret = 0
p = <optimized out>
q = <optimized out>
#4 0xb788969d in get_interface_list_findalldevs (err=0xbfffe978, err_str=0xbfffe974) at capture-pcap-util.c:174
il = 0x0
alldevs = 0xb789629c
dev = <optimized out>
if_info = <optimized out>
errbuf = "tun0: You don't have permission to capture on that device (socket: Operation not permitted)\000\000\000\203\267\342\071y\267Pi\211\267\000i\211\267\017\000\000\000ݍw\267\001\000\000\000\f\000\000\000Sni\267B\254l\267</\204\267\000s]\267h\350\377\277\066\000\204\267\001\000\000\000\001\000G_\022\000\000\000\004\000\000\000\060i\211\267\001\000\000\000\002\000\000\000 \000\000\000\002\000\000\000\001\000\000\000\335\177i\267\\\024y\267\306\177i\267\000\000G_\271~i\267āi\267\270\303k\267\020\000\000\000\020\000\000\000\000\000\000\000\200\303k\267\001\000\000\000\260\303k\267T\256"...
#5 0xb78879c0 in get_interface_list (err=0xbfffe978, err_str=0xbfffe974) at capture-pcap-util-unix.c:110
No locals.
#6 0xb788d9d2 in capture_interface_list (err=0xbfffe978, err_str=0xbfffe974) at dumpcap.c:797
No locals.
#7 0xb7889345 in capture_opts_trim_iface (capture_opts=0xb7895060, capture_device=0x0) at capture_opts.c:770
if_list = <optimized out>
if_info = <optimized out>
err = <optimized out>
err_str = <optimized out>
options = {name = 0x0, descr = 0x0, cfilter = 0x0, snaplen = -1217671968, linktype = 0, promisc_mode = -1217679788, buffer_size = -1073746668, monitor_mode = -1073747560}
#8 0xb788e6cd in main (argc=<optimized out>, argv=<optimized out>) at dumpcap.c:3850
opt = <optimized out>
arg_error = 0
action = {__sigaction_handler = {sa_handler = 0xb788b392 <capture_cleanup_handler>, sa_sigaction = 0xb788b392 <capture_cleanup_handler>}, sa_mask = {__val = {0 <repeats 32 times>}}, sa_flags = 0, sa_restorer = 0}
oldaction = {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = {__val = {0, 0, 5, 1598488576, 7, 1437274845, 14, 1598488577, 16, 3078868144, 0, 1, 3221219528, 3078170014, 8, 0, 4, 1437274845, 3079230456, 3078868144, 3221219576, 1437274845, 3078869408, 3078868144, 3221219576, 3078868144, 3078869408, 1, 3221219576, 3078278760, 3077292928, 3079221340}}, sa_flags = 0, sa_restorer = 0xaa71a380}
start_capture = 1
stats_known = 0
stats = {ps_recv = 0, ps_drop = 0, ps_ifdrop = 0}
list_interfaces = 0
list_link_layer_types = 0
print_bpf_code = 0
machine_readable = 0
print_statistics = 0
status = <optimized out>
run_once_args = 0
i = <optimized out>
A debugging session is active.

Inferior 1 [process 829] will be killed.

Quit anyway? (y or n) [answered Y; input not from terminal]

--
WBR, Alex.


pageexec at freemail

Jan 27, 2012, 3:48 PM

Post #14 of 27 (889 views)
Permalink
Re: Security Level: high/server/workstation/virtualization [In reply to]
On 28 Jan 2012 at 2:11, Alex Efros wrote:

> Hi!
>
> On Sat, Jan 28, 2012 at 01:07:43AM +0200, pageexec [at] freemail wrote:
> > > Program received signal SIGSEGV, Segmentation fault.
> > > 0xb75fd152 in readdir64 () from /lib/libc.so.6
> > x/16i $pc
> > x/16x $sp

gosh i knew i'd forgot something:

info reg

> > and based on the disasm i'll need more info later.

x/8x $esi


powerman at powerman

Jan 27, 2012, 4:11 PM

Post #15 of 27 (924 views)
Permalink
Re: Security Level: high/server/workstation/virtualization [In reply to]
Hi!

On Sat, Jan 28, 2012 at 01:07:43AM +0200, pageexec [at] freemail wrote:
> > Program received signal SIGSEGV, Segmentation fault.
> > 0xb75fd152 in readdir64 () from /lib/libc.so.6
> x/16i $pc
> x/16x $sp
>
> and based on the disasm i'll need more info later.

Program received signal SIGSEGV, Segmentation fault.
0xb74f9152 in readdir64 () from /lib/libc.so.6
(gdb) bt
#0 0xb74f9152 in readdir64 () from /lib/libc.so.6
#1 0xb75f77ea in scan_sys_class_net (devlistp=0xbfffd868,
errbuf=0xbfffd8bc "tun0: You don't have permission to capture on that device (socket: Operation not permitted)") at ./pcap-linux.c:1832
#2 0xb75fafff in pcap_platform_finddevs (alldevsp=0xbfffd868,
errbuf=0xbfffd8bc "tun0: You don't have permission to capture on that device (socket: Operation not permitted)") at ./pcap-linux.c:2081
#3 0xb75fd232 in pcap_findalldevs (alldevsp=0xbfffd8b8,
errbuf=0xbfffd8bc "tun0: You don't have permission to capture on that device (socket: Operation not permitted)") at ./fad-getad.c:275
#4 0xb778569d in get_interface_list_findalldevs (err=0xbfffda88, err_str=0xbfffda84)
at capture-pcap-util.c:174
#5 0xb77839c0 in get_interface_list (err=0xbfffda88, err_str=0xbfffda84)
at capture-pcap-util-unix.c:110
#6 0xb77899d2 in capture_interface_list (err=0xbfffda88, err_str=0xbfffda84) at dumpcap.c:797
#7 0xb7785345 in capture_opts_trim_iface (capture_opts=0xb7791060, capture_device=0x0)
at capture_opts.c:770
#8 0xb778a6cd in main (argc=<optimized out>, argv=<optimized out>) at dumpcap.c:3850
(gdb) x/16i $pc
=> 0xb74f9152 <readdir64+54>: cmpxchg %ecx,0x4(%esi)
0xb74f9156 <readdir64+58>: jne 0xb74f91dc
0xb74f915c <readdir64+64>: mov 0x10(%esi),%eax
0xb74f915f <readdir64+67>: lea 0x18(%esi),%edi
0xb74f9162 <readdir64+70>: jmp 0xb74f917d <readdir64+97>
0xb74f9164 <readdir64+72>: lea (%edi,%eax,1),%edx
0xb74f9167 <readdir64+75>: movzwl 0x10(%edx),%ecx
0xb74f916b <readdir64+79>: add %ecx,%eax
0xb74f916d <readdir64+81>: mov %eax,0x10(%esi)
0xb74f9170 <readdir64+84>: mov 0x8(%edx),%ecx
0xb74f9173 <readdir64+87>: mov %ecx,0x14(%esi)
0xb74f9176 <readdir64+90>: mov 0x4(%edx),%ecx
0xb74f9179 <readdir64+93>: or (%edx),%ecx
0xb74f917b <readdir64+95>: jne 0xb74f91b1 <readdir64+149>
0xb74f917d <readdir64+97>: cmp 0xc(%esi),%eax
0xb74f9180 <readdir64+100>: jb 0xb74f9164 <readdir64+72>
(gdb) x/16x $sp
0xbfffd508: 0x00000000 0xb7625c60 0xbfffd8bc 0xbfffd868
0xbfffd518: 0xbfffd7a8 0xb75f77ea 0x00000000 0x00000002
0xbfffd528: 0x00000000 0xb7625c60 0x00000000 0xb761385c
0xbfffd538: 0xbfffd558 0x75ab49e0 0xbfffd868 0xbfffd8bc
(gdb)

--
WBR, Alex.


powerman at powerman

Jan 27, 2012, 5:50 PM

Post #16 of 27 (899 views)
Permalink
Re: Security Level: high/server/workstation/virtualization [In reply to]
Hi!

On Sat, Jan 28, 2012 at 01:48:01AM +0200, pageexec [at] freemail wrote:
> gosh i knew i'd forgot something:

btw, glibc with debug has merged :)


(gdb) run
Starting program: /usr/bin/dumpcap
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0xb749f152 in __readdir64 (dirp=0x0) at ../sysdeps/unix/readdir.c:45
45 ../sysdeps/unix/readdir.c: No such file or directory.
in ../sysdeps/unix/readdir.c
(gdb)

(gdb) thread apply all bt full

Thread 1 (Thread 0xb73f16c0 (LWP 19994)):
#0 0xb749f152 in __readdir64 (dirp=0x0) at ../sysdeps/unix/readdir.c:45
dp = <optimized out>
saved_errno = <optimized out>
#1 0xb759d7ea in scan_sys_class_net (devlistp=0xbfffe488,
errbuf=0xbfffe4dc "tun0: You don't have permission to capture on that device (socket: Operation not permitted)") at ./pcap-linux.c:1832
sys_class_net_d = 0x0
fd = 7
ent = <optimized out>
p = <optimized out>
name = "\261\236N\267\314\341\377\277.\244[.\267\364\342\377\277\334\344\377\277\000\000\000\000\314\341\377\277\377\000\000\000\001\200\255\373\334\344\377\277\334\344\377\277\334\344\377\277\334\344\377\277\067\345\377\277\333\345\377\277\334\344\377\277\333\345\377\277", '\000' <repeats 20 times>, "\030\023\000\000\004\000\000\000T\316U\267\000\000\000\000\000\000\000\000\331\274s\267\203\003(\003\230\202s\267\324\274s\267\000\000\000\000`\274\\\267\020\240s\267\220\210G\267\230\342\377\277\211EZ\267\020\240s\267\377\377\000\000\325\\H\267(pZ\267v\000\000\000\271\236S\267\304\241S\267\270\343U\267\000\311U\267\000\000\000\000\324\274s\267\203\003(\003`\274\\\267\020\240s\267\300\346U\267\320\020\000\000\200\343U\267T\316U\267\200\343U\267\324\274s\267\250\342\377\277\243\275G\267\330\342\377\277\203\003(\003`\274\\\267\020\240s\267\330\342\377\277ZIZ\267\020\240s\267\324\274s\267\330\342\377\277\330\235N\267\334\344\377\277\000\001\000\000\001\000\000\000\203\003(\003`\274\\\267\020\240s\267\070\343\377\277AKZ\267\020\240s\267\000\001\000\000\001\000\000\000\377\377\377\377.\244[.\267\324\274s\267\370\237[.\267\064\241s\267\000\000\000\000\000\000\000\000D\000\000\000\334\344\377\277T\316U\267\000\000\000\000\331bO\267\203\003(\003\020eO\267\354\343\377\277\034\263s\267`\274\\\267\000\000\000\000\324\274s\267\250\343\377\277\341MZ\267\324\274s\267D\000\000\000\364wG\267\000\000\000\000\334\344\377\277\005\000\000\000\214\325S\267\234\236S\267"...
q = <optimized out>
ifrflags = {ifr_ifrn = {
ifrn_name = "T\316U\267l\342\377\277\334\344\377\277\270\342\377\277"}, ifr_ifru = {
ifru_addr = {sa_family = 40625,
---Type <return> to continue, or q <return> to quit---
sa_data = "N\267l\342\377\277\334\344\377\277\270\342\377\277"}, ifru_dstaddr = {
sa_family = 40625, sa_data = "N\267l\342\377\277\334\344\377\277\270\342\377\277"},
ifru_broadaddr = {sa_family = 40625,
sa_data = "N\267l\342\377\277\334\344\377\277\270\342\377\277"}, ifru_netmask = {
sa_family = 40625, sa_data = "N\267l\342\377\277\334\344\377\277\270\342\377\277"},
ifru_hwaddr = {sa_family = 40625,
sa_data = "N\267l\342\377\277\334\344\377\277\270\342\377\277"},
ifru_flags = -24911, ifru_ivalue = -1219584335, ifru_mtu = -1219584335, ifru_map = {
mem_start = 3075382961, mem_end = 3221217900, base_addr = 58588, irq = 255 '\377',
dma = 191 '\277', port = 184 '\270'},
ifru_slave = "\261\236N\267l\342\377\277\334\344\377\277\270\342\377\277",
ifru_newname = "\261\236N\267l\342\377\277\334\344\377\277\270\342\377\277",
ifru_data = 0xb74e9eb1, ifru_settings = {type = 3075382961, size = 3221217900,
ifs_ifsu = {raw_hdlc = 0xbfffe4dc, cisco = 0xbfffe4dc, fr = 0xbfffe4dc,
fr_pvc = 0xbfffe4dc, fr_pvc_info = 0xbfffe4dc, sync = 0xbfffe4dc,
te1 = 0xbfffe4dc}}}}
ret = 1
#2 0xb75a0fff in pcap_platform_finddevs (alldevsp=0xbfffe488,
errbuf=0xbfffe4dc "tun0: You don't have permission to capture on that device (socket: Operation not permitted)") at ./pcap-linux.c:2081
ret = <optimized out>
#3 0xb75a3232 in pcap_findalldevs (alldevsp=0xbfffe4d8,
errbuf=0xbfffe4dc "tun0: You don't have permission to capture on that device (socket: Operation not permitted)") at ./fad-getad.c:275
devlist = 0x0
ifap = 0xb773b328
ifa = 0x0
addr = <optimized out>
netmask = <optimized out>
broadaddr = <optimized out>
dstaddr = <optimized out>
---Type <return> to continue, or q <return> to quit---
addr_size = <optimized out>
broadaddr_size = <optimized out>
dstaddr_size = <optimized out>
ret = 0
p = <optimized out>
q = <optimized out>
#4 0xb772b69d in get_interface_list_findalldevs (err=0xbfffe6a8, err_str=0xbfffe6a4)
at capture-pcap-util.c:174
il = 0x0
alldevs = 0xb773829c
dev = <optimized out>
if_info = <optimized out>
errbuf = "tun0: You don't have permission to capture on that device (socket: Operation not permitted)\000\000\000m\267\342Yc\267P\211s\267\000\211s\267\017\000\000\000\335\255a\267\001\000\000\000\f\000\000\000S\216S\267B\314V\267<On\267\000\223G\267\230\345\377\277\066 n\267\001\000\000\000\001\000G_\022\000\000\000\004\000\000\000\060\211s\267\001\000\000\000\002\000\000\000 \000\000\000\002\000\000\000\001\000\000\000\335\237S\267\\4c\267\306\237S\267\000\000G_\271\236S\267\304\241S\267\270\343U\267\020\000\000\000\020\000\000\000\000\000\000\000\200\343U\267\001\000\000\000\260\343U\267T\316U\267\200\343U\267\061Ts\267"...
#5 0xb77299c0 in get_interface_list (err=0xbfffe6a8, err_str=0xbfffe6a4)
at capture-pcap-util-unix.c:110
No locals.
#6 0xb772f9d2 in capture_interface_list (err=0xbfffe6a8, err_str=0xbfffe6a4) at dumpcap.c:797
No locals.
#7 0xb772b345 in capture_opts_trim_iface (capture_opts=0xb7737060, capture_device=0x0)
at capture_opts.c:770
if_list = <optimized out>
if_info = <optimized out>
err = <optimized out>
err_str = <optimized out>
options = {name = 0x0, descr = 0x0, cfilter = 0x0, snaplen = -1219105568, linktype = 0,
---Type <return> to continue, or q <return> to quit---
promisc_mode = -1219113388, buffer_size = -1073747388, monitor_mode = -1073748280}
#8 0xb77306cd in main (argc=<optimized out>, argv=<optimized out>) at dumpcap.c:3850
opt = <optimized out>
arg_error = 0
action = {__sigaction_handler = {sa_handler = 0xb772d392 <capture_cleanup_handler>,
sa_sigaction = 0xb772d392 <capture_cleanup_handler>}, sa_mask = {__val = {
0 <repeats 32 times>}}, sa_flags = 0, sa_restorer = 0}
oldaction = {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = {__val = {
0, 0, 5, 1598488576, 7, 52953987, 14, 1598488577, 16, 3077434544, 0, 1, 3221218808,
3076736414, 8, 0, 4, 52953987, 3077796856, 3077434544, 3221218856, 52953987,
3077435808, 3077434544, 3221218856, 3077434544, 3077435808, 1, 3221218856,
3076845160, 3075859328, 3077787740}}, sa_flags = 0, sa_restorer = 0xac8c8380}
start_capture = 1
stats_known = 0
stats = {ps_recv = 0, ps_drop = 0, ps_ifdrop = 0}
list_interfaces = 0
list_link_layer_types = 0
print_bpf_code = 0
machine_readable = 0
print_statistics = 0
status = <optimized out>
run_once_args = 0
i = <optimized out>
(gdb)

(gdb) x/16i $pc
=> 0xb749f152 <__readdir64+54>: cmpxchg %ecx,0x4(%esi)
0xb749f156 <__readdir64+58>: jne 0xb749f1dc <_L_lock_22>
0xb749f15c <__readdir64+64>: mov 0x10(%esi),%eax
0xb749f15f <__readdir64+67>: lea 0x18(%esi),%edi
0xb749f162 <__readdir64+70>: jmp 0xb749f17d <__readdir64+97>
0xb749f164 <__readdir64+72>: lea (%edi,%eax,1),%edx
0xb749f167 <__readdir64+75>: movzwl 0x10(%edx),%ecx
0xb749f16b <__readdir64+79>: add %ecx,%eax
0xb749f16d <__readdir64+81>: mov %eax,0x10(%esi)
0xb749f170 <__readdir64+84>: mov 0x8(%edx),%ecx
0xb749f173 <__readdir64+87>: mov %ecx,0x14(%esi)
0xb749f176 <__readdir64+90>: mov 0x4(%edx),%ecx
0xb749f179 <__readdir64+93>: or (%edx),%ecx
0xb749f17b <__readdir64+95>: jne 0xb749f1b1 <__readdir64+149>
0xb749f17d <__readdir64+97>: cmp 0xc(%esi),%eax
0xb749f180 <__readdir64+100>: jb 0xb749f164 <__readdir64+72>
(gdb)

(gdb) x/16x $sp
0xbfffe128: 0x00000000 0xb75cbc60 0xbfffe4dc 0xbfffe488
0xbfffe138: 0xbfffe3c8 0xb759d7ea 0x00000000 0x00000002
0xbfffe148: 0x00000000 0xb75cbc60 0x00000000 0xb75b985c
0xbfffe158: 0xbfffe178 0x03280383 0xbfffe488 0xbfffe4dc
(gdb)

(gdb) info reg
eax 0x0 0
ecx 0x1 1
edx 0x0 0
ebx 0xb755ce54 -1219113388
esp 0xbfffe128 0xbfffe128
ebp 0xbfffe138 0xbfffe138
esi 0x0 0
edi 0xbfffe488 -1073748856
eip 0xb749f152 0xb749f152 <__readdir64+54>
eflags 0x10246 [ PF ZF IF RF ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51

(gdb) x/8x $esi
0x0: Cannot access memory at address 0x0
(gdb)

--
WBR, Alex.


powerman at powerman

Jan 27, 2012, 6:10 PM

Post #17 of 27 (899 views)
Permalink
Re: Security Level: high/server/workstation/virtualization [In reply to]
Hi!

On Sat, Jan 28, 2012 at 03:50:22AM +0200, Alex Efros wrote:
> #0 0xb749f152 in __readdir64 (dirp=0x0) at ../sysdeps/unix/readdir.c:45
> dp = <optimized out>
> saved_errno = <optimized out>
> #1 0xb759d7ea in scan_sys_class_net (devlistp=0xbfffe488,
> errbuf=0xbfffe4dc "tun0: You don't have permission to capture on that device (socket: Operation not permitted)") at ./pcap-linux.c:1832
> sys_class_net_d = 0x0

Ok, I'm not a C developer (you see, I don't even know how to use gdb), but
with so much information even I see what's the problem is:

in libpcap-1.1.1-r1:
pcap-linux.c:1816:

sys_class_net_d = opendir("/sys/class/net");
if (sys_class_net_d == NULL && errno == ENOENT)
return (0);
...
for (;;) {
errno = 0;
ent = readdir(sys_class_net_d);

the second line with if looks just plain wrong. Moreover, as far as I see,
in libpcap-1.2.1 they've already fixed this:
pcap-linux.c:1949:

sys_class_net_d = opendir("/sys/class/net");
if (sys_class_net_d == NULL) {
if (errno == ENOENT)
return (0);
(void)snprintf(errbuf, PCAP_ERRBUF_SIZE,
"Can't open /sys/class/net: %s", pcap_strerror(errno));
return (-1);
}

So, I'm going to upgrade libpcap to latest ~x86 version and see is this
really fix this bug… Okay, here it is:

$ dumpcap
dumpcap: Can't get list of interfaces: Can't open /sys/class/net: Permission denied

So, wireshark still doesn't work on hardened under non-root, but doesn't
crash anymore, that's a big progress.

--
WBR, Alex.


powerman at powerman

Jan 27, 2012, 6:28 PM

Post #18 of 27 (890 views)
Permalink
Re: Security Level: high/server/workstation/virtualization [In reply to]
Hi!

But… as far as I see, it was just _one_ attempt to access NULL pointer
because of very usual bug. The questions is, why is that triggered
CONFIG_GRKERNSEC_BRUTE? Isn't word "brute" suppose many similar incidents
happened in short period of time, not just one? As for me, killing all
user's processes and disabling it for 15 minutes after single attempt to
access NULL pointer sounds too cruel.

--
WBR, Alex.


powerman at powerman

Jan 27, 2012, 6:35 PM

Post #19 of 27 (888 views)
Permalink
Re: Security Level: high/server/workstation/virtualization [In reply to]
Hi!

On Sat, Jan 28, 2012 at 01:02:40AM +0200, Alex Efros wrote:
> > can you generate a coredump and see what the backtrace shows?
>
> Actually I can't get core. :-/ Look:
>
> I've re-emerged wireshark using this:
>
> # CFLAGS="-march=prescott -O1 -pipe -ggdb" \
> FEATURES="userpriv usersandbox userfetch parallel-fetch nostrip" \
> emerge wireshark
>
> Now:
>
> $ sudo zgrep ELF_CORE /proc/config.gz
> CONFIG_ELF_CORE=y
> $ cat /proc/sys/kernel/core_pattern
> core
> $ grep core /etc/security/limits.conf | grep -v '^#'
> * soft core unlimited
> $ cat /etc/limits.conf
> * C20480
> $ ulimit -c unlimited
> $ ulimit -c
> unlimited
> $ dumpcap
> Segmentation fault
> $ ls -l core
> ls: cannot access core: No such file or directory

And one more questions - why core wasn't dumped here?

I've even tried to log in in text mode console after editing both
limits.conf files and run dumpcap there - in case these limits apply on
user's login, and can't affect anything in the middle of X session - but
that doesn't helps too.

--
WBR, Alex.


pageexec at freemail

Jan 28, 2012, 4:02 AM

Post #20 of 27 (886 views)
Permalink
Re: Security Level: high/server/workstation/virtualization [In reply to]
On 28 Jan 2012 at 4:35, Alex Efros wrote:

> > $ dumpcap
> > Segmentation fault
> > $ ls -l core
> > ls: cannot access core: No such file or directory
>
> And one more questions - why core wasn't dumped here?

check /proc/sys/fs/suid_dumpable


pageexec at freemail

Jan 28, 2012, 4:09 AM

Post #21 of 27 (895 views)
Permalink
Re: Security Level: high/server/workstation/virtualization [In reply to]
On 28 Jan 2012 at 4:28, Alex Efros wrote:

> Hi!
>
> But... as far as I see, it was just _one_ attempt to access NULL pointer
> because of very usual bug. The questions is, why is that triggered
> CONFIG_GRKERNSEC_BRUTE? Isn't word "brute" suppose many similar incidents
> happened in short period of time, not just one? As for me, killing all
> user's processes and disabling it for 15 minutes after single attempt to
> access NULL pointer sounds too cruel.

you should probably read the config help about this option, your questions
are answered there. you made a suid executable crash, you wouldn't want an
attacker to be able to get away with it either (just think of the recent
/proc/pid/mem bug, the *only* thing that can save you is if you use grsec
and enable this very brute force protection option). if you don't care about
any of this on your personal desktop then just don't enable it ;).


pageexec at freemail

Jan 28, 2012, 4:12 AM

Post #22 of 27 (888 views)
Permalink
Re: Security Level: high/server/workstation/virtualization [In reply to]
On 28 Jan 2012 at 4:10, Alex Efros wrote:

> $ dumpcap
> dumpcap: Can't get list of interfaces: Can't open /sys/class/net: Permission denied

i think it's GRKERNSEC_SYSFS_RESTRICT that could cause this, do you have it enabled?


powerman at powerman

Jan 28, 2012, 5:23 AM

Post #23 of 27 (891 views)
Permalink
Re: Security Level: high/server/workstation/virtualization [In reply to]
Hi!

On Sat, Jan 28, 2012 at 02:12:19PM +0200, pageexec [at] freemail wrote:
> > $ dumpcap
> > dumpcap: Can't get list of interfaces: Can't open /sys/class/net: Permission denied
>
> i think it's GRKERNSEC_SYSFS_RESTRICT that could cause this, do you have it enabled?

Hmm. Sure. You think I shouldn't have it enabled?
dumpcap is suid, why it can't access it? Or it doesn't execute as root
already/yet at point when it try to enumerate available interfaces?
If this is the case, then it looks like one more bug to fix in dumpcap…

> > And one more questions - why core wasn't dumped here?
>
> check /proc/sys/fs/suid_dumpable

0. Thanks.

--
WBR, Alex.


powerman at powerman

Jan 28, 2012, 5:33 AM

Post #24 of 27 (924 views)
Permalink
Re: Security Level: high/server/workstation/virtualization [In reply to]
Hi!

On Sat, Jan 28, 2012 at 03:23:58PM +0200, Alex Efros wrote:
> > i think it's GRKERNSEC_SYSFS_RESTRICT that could cause this, do you have it enabled?
> Hmm. Sure. You think I shouldn't have it enabled?

Okay, I've disabled it: running wireshark as root probably create more
security risks than disabling this option. But this doesn't really solved
this issue:

$ dumpcap
dumpcap: Can't get list of interfaces: Can't open netlink socket 93:Protocol not supported

--
WBR, Alex.


pageexec at freemail

Jan 28, 2012, 10:28 AM

Post #25 of 27 (897 views)
Permalink
Re: Security Level: high/server/workstation/virtualization [In reply to]
On 28 Jan 2012 at 15:23, Alex Efros wrote:

> On Sat, Jan 28, 2012 at 02:12:19PM +0200, pageexec [at] freemail wrote:
> > > $ dumpcap
> > > dumpcap: Can't get list of interfaces: Can't open /sys/class/net: Permission denied
> >
> > i think it's GRKERNSEC_SYSFS_RESTRICT that could cause this, do you have it enabled?
>
> Hmm. Sure. You think I shouldn't have it enabled?
> dumpcap is suid, why it can't access it? Or it doesn't execute as root
> already/yet at point when it try to enumerate available interfaces?
> If this is the case, then it looks like one more bug to fix in dumpcap...

you should at this point probably talk to spender or the grsecurity related
list/forum as all this is his stuff, not mine ;)

First page Previous page 1 2 Next page Last page  View All Gentoo hardened RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.