Grsecurity patched kernel in Qubes

[Piotr Chmielnicki]

Hello,

My friends and I are using Qubes for a while.

We would really appreciate to have a grsecurity patched kernel running
on ours VMs. I was able to compile such kernel (with the Xen option
enabled) but I don't know how to install/deploy it.

I'm sure a lot of qubes users would enjoy to have the possibility to run
VM's with a hardened kernel.

Can you help me ?

Thank you,

Piotr Chmielnicki

[7v5w7go9ub0o]

On 04/15/13 13:42, Piotr Chmielnicki wrote:
> Hello,
>
> My friends and I are using Qubes for a while.
>
> We would really appreciate to have a grsecurity patched kernel running
> on ours VMs. I was able to compile such kernel (with the Xen option
> enabled) but I don't know how to install/deploy it.
>
> I'm sure a lot of qubes users would enjoy to have the possibility to run
> VM's with a hardened kernel.

Excellent!

<http://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options>

[Marek Marczykowski]

Here are some implementation details:
http://wiki.qubes-os.org/trac/wiki/TemplateImplementation#modules.imgxvdd

The easiest way is to use kernel from here:
http://git.qubes-os.org/gitweb/?p=marmarek/linux-kernel.git;a=summary
and just add patches (remember to add them also to series-pvops.conf).
Then execute make rpms and install result kernel-qubes-vm package in dom0.

If you want install kernel manually, place it according to above wiki link.
Commands to create modules.img you can get here [1] and for initramfs here
[2]. The last one is especially important to include VM dracut hooks [3],
which prepares VM root device.

[1]
http://git.qubes-os.org/gitweb/?p=marmarek/linux-kernel.git;a=blob;f=kernel.spec;h=79d3e92a243dfdc9bff2a5cb45cbe1a0f437c097;hb=HEAD#l449
[2]
http://git.qubes-os.org/gitweb/?p=marmarek/linux-kernel.git;a=blob;f=kernel.spec;h=79d3e92a243dfdc9bff2a5cb45cbe1a0f437c097;hb=HEAD#l327
[3]
http://git.qubes-os.org/gitweb/?p=marmarek/linux-kernel.git;a=tree;f=vm-initramfs;h=f612501be52c4b1275a615d1f763f73f696d15d8;hb=HEAD
--
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab

[Joanna Rutkowska]

Just out of curiosity -- does grsecurity use /dev/random to get some
randomness e.g. for ASLR? If so, you might want to read this ticket
description and the linked thread:

http://wiki.qubes-os.org/trac/ticket/673

joanna.

[7v5w7go9ub0o]

Think the answer is yes.

.........from .config:

"....Larger entropy pools If you say Y here, the entropy pools used for
many features of Linux and grsecurity will be doubled in size. Since
several grsecurity features use additional randomness, it is recommended
that you say Y here. Saying Y here has a similar effect as modifying
/proc/sys/kernel/random/poolsize......"




Also, perhaps there is something interesting here?

" ..... pax_randomize_kstack() gathers entropy from the rdtsc
instruction (read time stamp counter) and applies it to bits 2-6 of
the kernel stack pointer. This means that 5 bits are randomized
providing a maximum shift of 128 bytes - this was deemed safe enough to
not cause kernel stack overflows yet give enough randomness to deter
guessing/brute forcing attempts.

The use of rdtsc is justified by the facts that we need a quick entropy
source and that by the time a remote attacker would get to execute his
code to exploit a kernel bug, enough system calls would have been issued
by the attacked process to accumulate more than 5 bits of 'real' entropy
in the randomized bits (this is why xor is used to apply the rdtsc
output).
Note that most likely due to its microarchitecture, the Intel P4 CPU
seems to always return the same value in the least significant bit of
the time stamp counter therefore we ignore it in kernels compiled for
the P4.
........"

<http://pax.grsecurity.net/docs/randkstack.txt>

[Piotr Chmielnicki]

Thank you.

I finaly was able to compile a Grsec patched Kernel basing my work on your 'linux-kernel' repository.
Some informations :

• I used the testing release of grsec with the 3.8.7 kernel.
• I had to comment the 3 last patches in series-pvops.conf
• I had to disable the 'staging' drivers.

What I still have to do :

• Review the kernel/grsec security options and reconfigure the kernel.
• Test it.
• Write a readme about changes.
• Put it on a public repository.

More coming soon !

Piotr Chmielnicki

[Piotr Chmielnicki]

Do you need any special privilege to compile the kernel ?

By the way, I got a lot of messages like this :

xz: /tmp/tmp.q0pniZHGf2: No such file or directory
objcopy: cannot open: /tmp/tmp.q0pniZHGf2.xz: No such file or directory

Is this normal ?

Piotr Chmielnicki

[Marek Marczykowski]

On 17.04.2013 19:25, Piotr Chmielnicki wrote:
> Do you need any special privilege to compile the kernel ?

Can be done as normal user. Then need to be installed in dom0 (so first copy
it there from VM/other host).

> By the way, I got a lot of messages like this :
>
> xz: /tmp/tmp.q0pniZHGf2: No such file or directory
> objcopy: cannot open: /tmp/tmp.q0pniZHGf2.xz: No such file or directory
>
> Is this normal ?

AFAIR yes.

[Piotr Chmielnicki]

On 04/17/13 19:57, Marek Marczykowski wrote:
> On 17.04.2013 19:25, Piotr Chmielnicki wrote:
>> Do you need any special privilege to compile the kernel ?
> Can be done as normal user. Then need to be installed in dom0 (so first copy
> it there from VM/other host).
>
>> By the way, I got a lot of messages like this :
>>
>> xz: /tmp/tmp.q0pniZHGf2: No such file or directory
>> objcopy: cannot open: /tmp/tmp.q0pniZHGf2.xz: No such file or directory
>>
>> Is this normal ?
> AFAIR yes.
>

For the moment I have a working kernel with almost every features of
Grsecurity enabled but the enabling PaX make the kernel crash at boot.

If someone have an idea about what's wrong ...

Piotr Chmielnicki

[7v5w7go9ub0o]

On 04/18/13 15:58, Piotr Chmielnicki wrote:
<snip>

> For the moment I have a working kernel with almost every features of
> Grsecurity enabled but the enabling PaX make the kernel crash at
> boot.
>
> If someone have an idea about what's wrong ...

Possibly you checked CONFIG_PAX_NOEXEC (Enforce non-executable pages)?

(breaks X on my box.)

[qlx]

Interesting... Piotr, what is the specific characteristics of your application
that leads you to choose grsecurity over SELinux ...do you specialize on certain services ???
thx q

 

[Piotr Chmielnicki]

On 04/18/13 22:51, qlx wrote:

On Monday, April 15, 2013 10:42:19 AM UTC-7, Piotr Chmielnicki wrote:

Hello,

My friends and I are using Qubes for a while.

We would really appreciate to have a grsecurity patched kernel running
on ours VMs. I was able to compile such kernel (with the Xen option
enabled) but I don't know how to install/deploy it.

I'm sure a lot of qubes users would enjoy to have the possibility to run
VM's with a hardened kernel.

Can you help me ?

Thank you,

Piotr Chmielnicki

Interesting... Piotr, what is the specific characteristics of your application

What I need is a general purpose (and compatible with a lot of hardware) secure kernel for my secure desktop environment. 

that leads you to choose grsecurity over SELinux ...do you specialize on certain services ???

SELinux is a set of features that allow the system administrator to set access rules by application for various resources. It does not provide additional security by itself. The additional security is provided by enforcing policies.

Grsecurity is a kernel patch that modifies some core functions of the kernel (related to memory and processes management, networking and so on) to make it more secure.

As I said, I need an "universal out of the box secure kernel" for my VMs, that's why I need more Grsecurity than SELinux.

thx q

 

Piotr Chmielnicki

[7v5w7go9ub0o]

On 04/19/13 13:05, Piotr Chmielnicki wrote:
> On 04/18/13 22:51, qlx wrote:

>> that leads you to choose grsecurity over SELinux ...do you
>> specialize on certain services ???
> SELinux is a set of features that allow the system administrator to
> set access rules by application for various resources. It does not
> provide additional security by itself. The additional security is
> provided by enforcing policies.
>
> Grsecurity is a kernel patch that modifies some core functions of
> the kernel (related to memory and processes management, networking
> and so on) to make it more secure.

And FWIW, Grsecurity can also provide access rules (activate RBAC),
and to a finer granularity than SELinux (as of a couple of years ago).
Also, Grsecurity has an RBAC "learning mode" that makes development and
tuning of rules quite painless.

<http://en.wikibooks.org/wiki/Grsecurity/The_RBAC_System>

[qlx]

Thanks Roger and Piotr!
That's indeed very interesting!
Based on that model, would it be possible  to provide a degree of At-Run-Time-Integrity measurements of
a) the VM and its file-system state, similar to what Tripwire-Enterprise is doing,
b) In-Core execution of code (to make sure that in-core objects are not modified or altered) similar to what FIPS140 and incore hashing is doing and
c) the hardware state,  that is drivers, firmware and binary code entities that resides in On-Board-Flash (NAND) memory including ACPI code, which is being executed on the processor without any checks ....(that are all those entities Dom0 knows nothing about)
to the effect that we can determine (by measurement) if a machine is compromised and by which means the attack was implemented.
So we could drop the trust model of VM and replace it with a measurement based objective set of hashes??
This would actually help a lot.
Thanks in advance.
q

[Joanna Rutkowska]

On 04/19/13 21:24, qlx wrote:
> Thanks Roger and Piotr!
> That's indeed very interesting!
> Based on that model, would it be possible to provide a degree of
> At-Run-Time-Integrity measurements of
> a) the VM and its file-system state, similar to what Tripwire-Enterprise is
> doing,
> b) In-Core execution of code (to make sure that in-core objects are not
> modified or altered) similar to what FIPS140 and incore hashing is doing
> and
> c) the hardware state, that is drivers, firmware and binary code entities
> that resides in On-Board-Flash (NAND) memory including ACPI code, which is
> being executed on the processor without any checks ....(that are all those
> entities Dom0 knows nothing about)
> to the effect that we can determine (by measurement) if a machine is
> compromised and by which means the attack was implemented.
> So we could drop the trust model of VM and replace it with a measurement
> based objective set of hashes??
> This would actually help a lot.
> Thanks in advance.
> q
>

What you're writing about above is a stream of stupidity. Ok, so you
learn a couple of technical terms, that's fine, but why, in the world,
are you now throwing all those terms into this short email, mixing them
all together without any sense?

A polite request to all members: please do not post proposals on topics
you have no clue about, as this only confuses other people, and does
more harm than good.

joanna.

[7v5w7go9ub0o]

On 04/19/13 15:24, qlx wrote:
> Thanks Roger and Piotr! That's indeed very interesting! Based on that
> model, would it be possible to provide a degree of
> At-Run-Time-Integrity measurements of a) the VM and its file-system
> state, similar to what Tripwire-Enterprise is doing, b) In-Core
> execution of code (to make sure that in-core objects are not modified
> or altered) similar to what FIPS140 and incore hashing is doing

Understanding that I am a newbie,

I believe the answer is yes to both read or executed, and I believe it
is now available in all contemporary kernels. Just looked at the menuconfig
of my kernel (Gentoo x86_64 3.8.7-hardened Kernel) and found the
following option:

"CONFIG_IMA:

The Trusted Computing Group(TCG) runtime Integrity
Measurement Architecture(IMA) maintains a list of hash
values of executables and other sensitive system files,
as they are read or executed. If an attacker manages
to change the contents of an important system file
being measured, we can tell.


If your system has a TPM chip, then IMA also maintains
an aggregate integrity value over this list inside the
TPM hardware, so that the TPM can prove to a third party
whether or not critical system files have been modified.
Read <http://www.usenix.org/events/sec04/tech/sailer.html> "

> and c) the hardware state, that is drivers, firmware and binary code
> entities that resides in On-Board-Flash (NAND) memory including ACPI
> code, which is being executed on the processor without any checks
> ....(that are all those entities Dom0 knows nothing about) to the
> effect that we can determine (by measurement) if a machine is
> compromised and by which means the attack was implemented. So we
> could drop the trust model of VM and replace it with a measurement
> based objective set of hashes??

I think this is something secure boot will eventually handle before
starting XEN. I anticipate a new laptop as Qubes matures, and this
capability is on my personal hardware checklist

[qlx]

Roger, thanks for your qualified response!
it would tempting to try a working version of a hardened kernel ( with these additional features).
Do you plan to to make a kernel available through an update repository of else?
thx q

[7v5w7go9ub0o]

On 04/19/13 19:46, qlx wrote:
> Roger, thanks for your qualified response! it would tempting to try
> a working version of a hardened kernel ( with these additional
> features). Do you plan to to make a kernel available through an
> update repository of else? thx q
>

ISTM sharing my kernel would be tricky:

1. I don't know much - these other folks are proper developers.

2. I'm using a Gentoo hardened tool-chain which is likely incompatible
with your box.

3. My kernel is trimmed down to a minimal size and "hard-wired" for my
particular hardware - e.g. my CPU only; e.g. the only lkm is for an Nvidia
graphics card.

4. Kernel is patched for loop-AES encryption - and you'd have to build a
custom boot process (e.g. I'm using lilo)

Even if Piotr Chmielnicki has an operational, patched standard Qubes
fedora kernel/VM and hasn't trimmed it down (i.e. it'll work on your
hardware), it would be a task tar-ing up his kernel and modules
directories, and plugging them into /usr/src, /lib/modules, and grub;
and somehow getting it to work (.... a lot of other stuff would have to
be compatible).

Best to wait for Piotr to report back and hopefully get others here
enthusiastic with the prospect of using hardened kernels in their Qubes
Linux VMs.

I'm going to apply Joanna's advice to myself ( "...please do not post
proposals on topics I have no clue about.." ) and stop here.

[Piotr Chmielnicki]

Hello again,

I did it. You can find the hardened kernel here :

https://github.com/PiotrC/grsec4qubes/

The kernel works in qubes VMs and also in dom0.
Read the read-me, fetch it, build it, try it and don't hesitate to give
me a feed back.

Feel free to add it in to official qubes repos.

Piotr Chmielnicki

[Joanna Rutkowska]

So, how did you solve the /dev/random starvation problem that occurs in
Qubes AppVMs as I wrote about earlier?

joanna.

[Piotr Chmielnicki]

First, I still use the kernel ALSR (not the one provided by PaX) so my
grsec kernel should not consume much more randomness than the standard one.
Then I enabled larger entropy pools (CONFIG_GRKERNSEC_RANDNET) and early
boot entropy collection (CONFIG_PAX_LATENT_ENTROPY) to get and keep more
entropy.

I don't know if it efficiently solves the problem but it might help.
> joanna.
Piotr

[Joanna Rutkowska]

I don't think it can solve the randomness problem.

Anyway, a more relevant question that should be asked here is what
specific attacks you're attempting to prevent/make difficult with this
kernel?

I'm sure you probably already saw this file that is in every Qubes VM:

http://git.qubes-os.org/?p=marmarek/core-agent-linux.git;a=blob;f=misc/qubes.sudoers;h=8087a90a8c0a6f81d4fe45905a6aa9462de2a7ce;hb=HEAD

... right?

joanna.

[Piotr Chmielnicki]

I know.
What I'm mainly trying to do is to make harder for someone to exploit
software that I use (email client, browser and so on). Additional
features like freed memory sanitizing or network protections also
interests me.
> joanna.
>
>
Piotr

[7v5w7go9ub0o]

On 04/20/13 18:09, Piotr Chmielnicki wrote:

> What I'm mainly trying to do is to make harder for someone to exploit
> software that I use (email client, browser and so on). Additional
> features like freed memory sanitizing or network protections also
> interests me.

Ditto - I too was thinking of VM templates.

One can also get pop-up warnings when shenanigans are blocked in either
OS attacks and/or, when RBAC is also used, if the VM is acting in an
unusual way (e.g. a browser extension or plugin tries to communicate
outside in an unauthorized manner or to an unauthorized destination;
tries to look at, or change something it shouldn't).

Obviously a temp-VM would be uninjured after restarting, and presumably
one would restart them fairly regularly or after heavy use......

But real-time protection and warnings both help safeguard, and advise you
that mischief or malfunction is afoot and it's time to shut that VM down
before a compromise can get your stuff (if GRSEC doesn't shut it down -
optional).

[Joanna Rutkowska]

Let me get it straight -- I see *zero* security benefit of using things
such as RBAC or MAC, or whatever other security policing inside Qubes
AppVMs. The most important reason for this is that none of those provide
you isolation on X-level (GUI level).

Providing strong ASLR might be a good idea, but I'm not quite sure what
advantage does it have over the standard ASLR that we already have in
our kernel, e.g. (these show the first few lines of the memory maps for
the same thunderbird process, started twice without VM reboot):

[user@work ~]$ cat /proc/969/maps | head
00400000-00413000 r-xp 00000000 fd:00 432634
/usr/lib64/thunderbird/thunderbird
00612000-00613000 r--p 00012000 fd:00 432634
/usr/lib64/thunderbird/thunderbird
00613000-00614000 rw-p 00013000 fd:00 432634
/usr/lib64/thunderbird/thunderbird
7f0d6a700000-7f0d6a800000 rw-p 00000000 00:00 0
7f0d6bdfd000-7f0d6bdfe000 ---p 00000000 00:00 0
7f0d6bdfe000-7f0d6c5fe000 rw-p 00000000 00:00 0
7f0d6d600000-7f0d6d700000 rw-p 00000000 00:00 0
7f0d6e9f9000-7f0d6e9fa000 ---p 00000000 00:00 0
7f0d6e9fa000-7f0d6f1fa000 rw-p 00000000 00:00 0
[stack:8141]
7f0d6fe00000-7f0d6ff00000 rw-p 00000000 00:00 0
[user@work ~]$ cat /proc/8260/maps | head
00400000-00413000 r-xp 00000000 fd:00 432634
/usr/lib64/thunderbird/thunderbird
00612000-00613000 r--p 00012000 fd:00 432634
/usr/lib64/thunderbird/thunderbird
00613000-00614000 rw-p 00013000 fd:00 432634
/usr/lib64/thunderbird/thunderbird
7f724d8ff000-7f724d900000 ---p 00000000 00:00 0
7f724d900000-7f724e200000 rw-p 00000000 00:00 0
[stack:8328]
7f724e300000-7f724e400000 rw-p 00000000 00:00 0
7f724e500000-7f724e800000 rw-p 00000000 00:00 0
7f724e900000-7f724ea00000 rw-p 00000000 00:00 0
7f724eb00000-7f724ec00000 rw-p 00000000 00:00 0
7f724ed00000-7f724f000000 rw-p 00000000 00:00 0

Obviously we see that the main executable is not relocated, as it is not
PIC -- can grsec randomize these sections too?

What other anti-exploitation benefits does it provide (besides ASLR and
NX that, as I understand, is standard on x64 kernels anyway)? Can you
quote specific CONFIG_*'s that are responsible for those mechanisms?

joanna.

[7v5w7go9ub0o]

On 04/21/13 08:39, Joanna Rutkowska wrote:
> On 04/21/13 00:52, 7v5w7go9ub0o wrote:


>> But real-time protection and warnings both help safeguard, and advise you
>> that mischief or malfunction is afoot and it's time to shut that VM down
>> before a compromise can get your stuff (if GRSEC doesn't shut it down -
>> optional).
>>
>
> Let me get it straight -- I see *zero* security benefit of using things
> such as RBAC or MAC, or whatever other security policing inside Qubes
> AppVMs. The most important reason for this is that none of those provide
> you isolation on X-level (GUI level).

- Until called to action, the hardening and RBAC are each transparent
to the user. There is only the modified kernel, the standard kernel log
within the VM, a (protected) user-space file within the VM containing
rules for what is allowed, and any log monitoring software used within
the VM to document unusual activity (mine pops up an xmessage when a
grsecurity log entry occurs).

- All of that would be completely contained within the VM (popups would
not occur in dom0), and your current GUI would look at xmessages that may
popup within the VM

- Perhaps RBAC xmessages within the VM could be considered an Intrusion
Detection System - detecting intrusions from the WAN, and from the
software distribution chain.

- RBAC can also finely control WAN access - e.g. restricting a
browser-equipped mail client (e.g. Thunderbird) to https connections to
specific mail server addresses.

(fwiw, I've temporarily deactivated RBAC 'til recent improvements have
settled down.)

> Providing strong ASLR might be a good idea, but I'm not quite sure what
> advantage does it have over the standard ASLR that we already have in
> our kernel, e.g. (these show the first few lines of the memory maps for
> the same thunderbird process, started twice without VM reboot):

I don't know if it is superior to standard (see below).

<snip>

> Obviously we see that the main executable is not relocated, as it is not
> PIC -- can grsec randomize these sections too?

3.4 Address Space Layout Randomization

Configuration option: CONFIG_PAX_ASLR
By saying Y here you can choose to randomize the following areas:
- top of the task's kernel stack
- top if the task's userland stack
- base address for mmap() requests that do not specify one (this
includes all libraries)
- base address of the main executable

Configuration option: CONFIG_PAX_RANDKSTACK
By saying Y here the kernel will randomize every task's kernel stack on
every system call. This will not only force an attacker to guess it but
also prevent him from making use of possible leaked information about it.

Configuration option: CONFIG_PAX_RANDUSTACK
By saying Y here the kernel will randomize every task's userland stack.
The randomization is done in two steps where the second one may apply a
big amount of shift to the top of the stack and cause problems for
programs that want to use lots of memory (more than 2.5 GB if SEGMEXEC
is not active, or 1.25 GB when it is). (this can be disabled for those
programs)


Configuration option: CONFIG_PAX_RANDMMAP
By saying Y here the kernel will use a randomized base address for
mmap() requests that do not specify one themselves. As a result all
dynamically loaded libraries will appear at random addresses and
therefore be harder to exploit by a technique where an attacker attempts
to execute library code for his purposes (e.g. spawn a shell from an
exploited program that is running at an elevated privilege level).

Furthermore, if a program is relinked as a dynamic ELF file, its base
address will be randomized as well, completing the fill randomization of
the address space layout. Attacking such programs becomes a guess game.

> What other anti-exploitation benefits does it provide (besides ASLR and
> NX that, as I understand, is standard on x64 kernels anyway)?

There are too many to list in this post. This page rather concisely
summarizes the additional anti-exploitation benefits.

<http://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options>

> Can you quote specific CONFIG_*'s that are responsible for those mechanisms?

Yes (follows):


(sigh.....looking at the list from my kernel config, I realize that I
need to review my settings - much has changed in the last few years )



# PaX
#
CONFIG_PAX=y

#
# PaX Control
#
# CONFIG_PAX_SOFTMODE is not set
CONFIG_PAX_PT_PAX_FLAGS=y
# CONFIG_PAX_XATTR_PAX_FLAGS is not set
# CONFIG_PAX_NO_ACL_FLAGS is not set
CONFIG_PAX_HAVE_ACL_FLAGS=y
# CONFIG_PAX_HOOK_ACL_FLAGS is not set

#
# Non-executable pages
#
# CONFIG_PAX_NOEXEC is not set
# CONFIG_PAX_KERNEXEC is not set
CONFIG_PAX_KERNEXEC_PLUGIN_METHOD=""

# Address Space Layout Randomization
#
CONFIG_PAX_ASLR=y
CONFIG_PAX_RANDKSTACK=y
CONFIG_PAX_RANDUSTACK=y
CONFIG_PAX_RANDMMAP=y

#
# Miscellaneous hardening features
#
# CONFIG_PAX_MEMORY_STACKLEAK is not set
# CONFIG_PAX_MEMORY_STRUCTLEAK is not set
# CONFIG_PAX_MEMORY_UDEREF is not set
# CONFIG_PAX_REFCOUNT is not set
CONFIG_PAX_CONSTIFY_PLUGIN=y
CONFIG_PAX_USERCOPY=y
# CONFIG_PAX_USERCOPY_DEBUG is not set
# CONFIG_PAX_SIZE_OVERFLOW is not set
# CONFIG_PAX_LATENT_ENTROPY is not set

#
# Memory Protections
#
# CONFIG_GRKERNSEC_KMEM is not set
# CONFIG_GRKERNSEC_IO is not set
# CONFIG_GRKERNSEC_RAND_THREADSTACK is not set
CONFIG_GRKERNSEC_PROC_MEMMAP=y
CONFIG_GRKERNSEC_BRUTE=y
# CONFIG_GRKERNSEC_MODHARDEN is not set
# CONFIG_GRKERNSEC_HIDESYM is not set
# CONFIG_GRKERNSEC_KERN_LOCKOUT is not set


#
# Role Based Access Control Options
#
# CONFIG_GRKERNSEC_NO_RBAC is not set
# CONFIG_GRKERNSEC_ACL_HIDEKERN is not set
CONFIG_GRKERNSEC_ACL_MAXTRIES=3
CONFIG_GRKERNSEC_ACL_TIMEOUT=30

#
# Filesystem Protections
#
# CONFIG_GRKERNSEC_PROC is not set
CONFIG_GRKERNSEC_LINK=y
# CONFIG_GRKERNSEC_SYMLINKOWN is not set
CONFIG_GRKERNSEC_FIFO=y
CONFIG_GRKERNSEC_SYSFS_RESTRICT=y
# CONFIG_GRKERNSEC_ROFS is not set
# CONFIG_GRKERNSEC_DEVICE_SIDECHANNEL is not set
CONFIG_GRKERNSEC_CHROOT=y
CONFIG_GRKERNSEC_CHROOT_MOUNT=y
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y
CONFIG_GRKERNSEC_CHROOT_PIVOT=y
CONFIG_GRKERNSEC_CHROOT_CHDIR=y
CONFIG_GRKERNSEC_CHROOT_CHMOD=y
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y
CONFIG_GRKERNSEC_CHROOT_MKNOD=y
CONFIG_GRKERNSEC_CHROOT_SHMAT=y
CONFIG_GRKERNSEC_CHROOT_UNIX=y
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y
CONFIG_GRKERNSEC_CHROOT_NICE=y
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y
CONFIG_GRKERNSEC_CHROOT_CAPS=y

#
# Sysctl Support
#
CONFIG_GRKERNSEC_SYSCTL=y
CONFIG_GRKERNSEC_SYSCTL_ON=y

#
# Logging Options
#
CONFIG_GRKERNSEC_FLOODTIME=10
CONFIG_GRKERNSEC_FLOODBURST=4

#
# Kernel Auditing
#
# CONFIG_GRKERNSEC_AUDIT_GROUP is not set
# CONFIG_GRKERNSEC_EXECLOG is not set
# CONFIG_GRKERNSEC_RESLOG is not set
# CONFIG_GRKERNSEC_CHROOT_EXECLOG is not set
# CONFIG_GRKERNSEC_AUDIT_PTRACE is not set
# CONFIG_GRKERNSEC_AUDIT_CHDIR is not set
# CONFIG_GRKERNSEC_AUDIT_MOUNT is not set
# CONFIG_GRKERNSEC_SIGNAL is not set
# CONFIG_GRKERNSEC_FORKFAIL is not set
# CONFIG_GRKERNSEC_TIME is not set
# CONFIG_GRKERNSEC_PROC_IPADDR is not set

#
# Executable Protections
#
CONFIG_GRKERNSEC_DMESG=y
CONFIG_GRKERNSEC_HARDEN_PTRACE=y
# CONFIG_GRKERNSEC_PTRACE_READEXEC is not set
CONFIG_GRKERNSEC_SETXID=y
# CONFIG_GRKERNSEC_TPE is not set

#
# Network Protections
#
CONFIG_GRKERNSEC_RANDNET=y
CONFIG_GRKERNSEC_BLACKHOLE=y
CONFIG_GRKERNSEC_NO_SIMULT_CONNECT=y
# CONFIG_GRKERNSEC_SOCKET is not set

[Piotr Chmielnicki]

A list of few enabled features in the current kernel config that I use for qubes/grsec :

• CONFIG_GRKERNSEC_BRUTE is a protection against some bruteforcings of exploits.
• CONFIG_GRKERNSEC__KERN_LOCKUP enable a hard kernel response against suspicious activites.
• CONFIG_PAX_MEMORY_SANITIZE : freed memory sanitizing. Not a direct protection against exploits it could help to protect privacy in some cases.

These features don't bring a major improvement in the security of a Qubes OS environment, but they could help in some cases.

Piotr Chmielnicki

[Marty McFly]

I realize this is an old thread, but I think I have things to add.

On Sunday, April 21, 2013 2:39:30 PM UTC+2, joanna wrote:

Let me get it straight -- I see *zero* security benefit of using things
such as RBAC or MAC, or whatever other security policing inside Qubes
AppVMs. The most important reason for this is that none of those provide
you isolation on X-level (GUI level).

RBAC / MAC can also be used to prevent exploitation of a process. Most notably preventing access to things in /proc and /tmp:

/proc/self/environ, /proc/self/fd/* and other common input vectors for exploit writers.

I agree that once an attacker has establied a foothold on the system. FS-level RBAC/MAC has reduced value (though far from worthless).

Such frameworks can also be key to realizing that you are compromised.

 

Providing strong ASLR might be a good idea, but I'm not quite sure what
advantage does it have over the standard ASLR that we already have in
our kernel, e.g. (these show the first few lines of the memory maps for
the same thunderbird process, started twice without VM reboot):

[proof of Fedora shipping ET_EXEC ELF instead of ET_DYN like Gentoo Hardened]

IMO there's a very limited security advantage, but that's only because the current state of affairs is complete shit (unrandomized .text, all binaries publicly available from Fedora RPM repos). Another argument for compiling your own ET_DYN ELFs like Gentoo Hardened does.

Obviously we see that the main executable is not relocated, as it is not
PIC -- can grsec randomize these sections too?

PaX (included in grsec) *can* actually do that, but with fewer random bits than with PIE executables (ET_DYN).

 

What other anti-exploitation benefits does it provide (besides ASLR and
NX that, as I understand, is standard on x64 kernels anyway)? Can you
quote specific CONFIG_*'s that are responsible for those mechanisms?

 

Here's a link to the options introduced: https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options

While I agree with you that grsec does not make local roots impossible, it does improve the security level significantly by patching entire bug classes.

I personally believe in separation of privileges and the principle of least privelege and I think it would be a shame not to consider the benefits that grsec offers.

As to the question of whether local access is as good as local root, I postulate that it is not, and that certain bugs will be much easier to exploit as a root user. Furthermore, doing so without setting off syslog alarms and similar will be easier if the user has local root access. For an example of Xen-related bug that was not exploitable as a local user, see: CVE-2007-4993: https://secunia.com/advisories/cve_reference/CVE-2007-4993/

Among my favorites are (in no particular order):

CONFIG_GRKERNSEC_KMEM: If you say Y here, /dev/kmem and /dev/mem< won't be allowed to be written to via mmap or otherwise to modify the running kernel. /dev/port will also not be allowed to be opened. If you have module support disabled, enabling this will close up four ways that are currently used to insert malicious code into the running kernel. *cut*

CONFIG_GRKERNSEC_IO: If you say Y here, all ioperm and iopl calls will return an error. Ioperm and iopl can be used to modify the running kernel.

CONFIG_GRKERNSEC_PROC + CONFIG_GRKERNSEC_PROC_USER + CONFIG_GRKERNSEC_LINK: Make local exploitation harder

CONFIG_GRKERNSEC_SYSFS_RESTRICT: If you say Y here, sysfs (the pseudo-filesystem mounted at /sys) and any filesystem normally mounted under it (e.g. 

debugfs) will only be accessible by root. These filesystems generally provide access to hardware and debug information that isn't appropriate for unprivilegedusers of the system. Sysfs and debugfs have also become a large source of new vulnerabilities, ranging from infoleaks to local compromise.

CONFIG_GRKERNSEC_SIGNAL: If you say Y here, certain important signals will be logged, such as SIGSEV, which will as a result inform you of when an error in a program occurred, which in some cases could mean a possible exploit attempt

CONFIG_PAX_MPROTECT: Enforcing W^X so you can't just do return-to-libc's mprotect(), forcing you to use ROP payloads (historically harder to construct reliably as they require more control over heap + stack)

CONFIG_PAX_KERNEXEC: This is the kernel land equivalent of PAGEEXEC and MPROTECT, that is, enabling this option will make it harder to inject and execute "foreign" code in kernel memory itself.

CONFIG_PAX_RANDKSTACK: By saying Y here the kernel will randomize every task's kernel stack on every system call. This will not only force an attacker to guess it but also prevent him from making use of possible leaked information about it.

CONFIG_PAX_MEMORY_SANITIZE: By saying Y here the kernel will erase memory pages as soon as they are freed. This is turn reduces the lifetime of data stored in the pages, making it less likely that sensitive information such as passwords, cryptographic secrets, etc. stay in memory for too long.

CONFIG_PAX_MEMORY_STACKLEAK: By saying Y here the kernel will erase the kernel stack before it returns from a system call. This in turn reduces the information that a kernel stack leak bug can reveal.

CONFIG_PAX_MEMORY_UDEREF: By saying Y here the kernel will be prevented from dereferencing userland pointers in contexts where the kernel expects only kernel pointers. This is both a useful runtime debugging feature and a security measure that prevents exploiting a class of kernel bugs.

CONFIG_PAX_REFCOUNT: By saying Y here the kernel will detect and prevent overflowing various (but not all) kinds of object reference counters. Such overflows can normally occur due to bugs only and are often, if not always, exploitable.

CONFIG_PAX_USERCOPY: By saying Y here the kernel will enforce the size of heap objects when they are copied in either direction between the kernel and userland, even if only a part of the heap object is copied. Specifically, this checking prevents information leaking from the kernel heap during kernel to userland copies (if the kernel heap object is otherwise fully initialized) and prevents kernel heap overflows during userland to kernel copies.