grsecurity forums

Hi,

I am having problems with encrypted home directories (Ubuntu-eCryptfs and grsecurity-stable 2.6.32.29)

I have enabled the hardening of kernel auto-load and I am fully aware of the problems that this causes with encrypted home dir, so, instead of compiling ECB and AES as modules I have built them into the kernel. And yet, upon user login I get (taken from dmesg):

Code: Select all

[   30.246995] grsec: denied kernel module auto-load of ecb(aes) by /sbin/mount.ecryptfs_private[mount.ecryptfs_:1143] uid/euid:1000/0 gid/egid:0/0, parent /bin/login[login:1119] uid/euid:0/0 gid/egid:0/0
[   30.247975] grsec: denied kernel module auto-load of ecb(aes)-all by /sbin/mount.ecryptfs_private[mount.ecryptfs_:1143] uid/euid:1000/0 gid/egid:0/0, parent /bin/login[login:1119] uid/euid:0/0 gid/egid:0/0

I am stumped since I don't know which modules I need to load with modprobe since I have no modules to load:

Code: Select all

modprobe -l | egrep '(ecb|aes|sha|crypt)'

returns

Code: Select all

kernel/crypto/crc32c.ko
kernel/drivers/md/dm-crypt.ko
kernel/drivers/crypto/padlock-aes.ko
kernel/drivers/crypto/padlock-sha.ko

Any help and clarification is welcomed

-M

Since I'm curious, have you tried:
- using ecryptfs with an older kernel and grsecurity?
- using ecryptfs with a vanilla kernel configured with the ecb and aes modules in the kernel?

There are also other things you could try:
- compile ecb and aes as modules
- disable the CONFIG_GRKERNSEC_MODHARDEN option
- load the modules before the ecryptfs starts
- use sysctl to set kernel.modules_disabled = 1 (after ecryptfs works)

You could use the standard system configuration to achieve this.
If it works you could try to re-enable the modharden option.

Is it just an issue of logging (says the module load was denied, but everything works properly) or do the encrypted home directories not work even when AES and ECB are compiled in?

-Brad

Since I'm curious, have you tried:
- using ecryptfs with an older kernel and grsecurity?
- using ecryptfs with a vanilla kernel configured with the ecb and aes modules in the kernel?

first question: No
second question: yes, it works (as it should)

Actually, in the eCryptfs FAQs they suggest to compile into the kernel everything except the file system:

Code: Select all

Recommended .config options (some options not available in older kernels):
CONFIG_EXPERIMENTAL=y
CONFIG_KEYS=y
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_AES=y
CONFIG_ECRYPT_FS=m

There are also other things you could try:
- compile ecb and aes as modules
- disable the CONFIG_GRKERNSEC_MODHARDEN option
- load the modules before the ecryptfs starts
- use sysctl to set kernel.modules_disabled = 1 (after ecryptfs works)

I do not like this solution since I am not sure this will offer the same degree of protection as CONFIG_GRKERNSEC_MODHARDEN. But I might be wrong.

spender wrote:Is it just an issue of logging (says the module load was denied, but everything works properly) or do the encrypted home directories not work even when AES and ECB are compiled in?

-Brad

Yes, it is a matter of logging from what I have observed. I was actually surprised that it worked (but then again those were not loadable modules)... it is kind of annoying tho

-M

Could you do me a favor? In kernel/kmod.c, before the return -EPERM from GRKERNSEC_MODHARDEN, could you add a WARN_ON(1) there and then send me the results (it should produce a stack trace)? I've been looking at the code paths that can request those modules, but they all seem to check if the cipher/template is already loaded before trying to request a module.

-Brad

spender wrote:Could you do me a favor? In kernel/kmod.c, before the return -EPERM from GRKERNSEC_MODHARDEN, could you add a WARN_ON(1) there and then send me the results (it should produce a stack trace)? I've been looking at the code paths that can request those modules, but they all seem to check if the cipher/template is already loaded before trying to request a module.

-Brad

Too late, man... In my latest kernel I am not using eCrypt anymore, partly because of the message... I know, overreaction... In any case, I will soon recompile a new kernel (2.6.32-35) and do what you suggest, but it might be tomorrow or the next week... I have other things scheduled, sorry about that.

-M

Hi,

I have good news. The next grsecurity patch will include a generic fix for the problem where non-existent modules being requested clutter the logs as denials.

-Brad