FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Hardened

 
 
LinkBack Thread Tools
 
Old 01-27-2012, 07:11 PM
Pavel Labushev
 
Default Security Level: high/server/workstation/virtualization

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.
 
Old 01-27-2012, 07:19 PM
Alex Efros
 
Default Security Level: high/server/workstation/virtualization

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.
 
Old 01-27-2012, 07:34 PM
 
Default Security Level: high/server/workstation/virtualization

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.
 
Old 01-27-2012, 07:40 PM
 
Default Security Level: high/server/workstation/virtualization

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?
 
Old 01-27-2012, 08:14 PM
Matthew Thode (prometheanfire)
 
Default Security Level: high/server/workstation/virtualization

On Fri, 27 Jan 2012 22:19:42 +0200
Alex Efros <powerman@powerman.name> 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)
 
Old 01-27-2012, 08:20 PM
Alex Efros
 
Default Security Level: high/server/workstation/virtualization

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.
 
Old 01-27-2012, 08:28 PM
"Francisco Blas Izquierdo Riera (klondike)"
 
Default Security Level: high/server/workstation/virtualization

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.
 
Old 01-27-2012, 10:02 PM
Alex Efros
 
Default Security Level: high/server/workstation/virtualization

Hi!

On Fri, Jan 27, 2012 at 10:40:43PM +0200, pageexec@freemail.hu 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_CLOE XEC) = -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.
 
Old 01-27-2012, 10:07 PM
Alex Efros
 
Default Security Level: high/server/workstation/virtualization

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.
 
Old 01-27-2012, 10:07 PM
 
Default Security Level: high/server/workstation/virtualization

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.
 

Thread Tools




All times are GMT. The time now is 07:58 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org