hardening patch for setuid code

[Marcus Meissner]

Sebastian Krahmer audited and hardened the setuid related code in ecryptfs-utils

most fixes are in pam_ecryptfs, some smaller ones in mount.ecryptfs_private

[Gleixner (gleixner)]

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1

See thread: http://forums.opensuse.org/english/other-forums/development/programming-scripting/408976-ecryptfs-setup-private-script-fails.html

There are 2 problems:

1. User has not the permission to mount - fix: setuid root for /sbin/mount.ecryptfs_private
2. Kernel modules are not loaded automatically. Needs ecryptfs and dependend modules

Reproducible: Always

Steps to Reproduce:
ecryptfs-mount-private
Actual Results:
error

Expected Results:
working

[Lnussel-k (lnussel-k)]

the package maintainer has not requested a setuid bit by default so far so the program is not audited whether it's actually safe to set it.

[Nrickert (nrickert)]

I think this is related.

I did set the suid bit on /sbin/mount.ecryptfs_private

After that, "ecryptfs-mount-private" is still broken. It has the appearance of working. The Private directory is mounted. But in the mounted ~/Private only the encrypted file names show.

If "modprobe ecryptfs" is run before "ecryptfs-mount-private" then it works fine.

It seems that "ecryptfs-mount-private" is loading the module, but is loading it too late for it to be usable for decrypting the file names.

After "ecryptfs-mount-private" you can run "ecryptfs-umount-private" followed by another "ecryptfs-mount-private" to get it mounted properly. Or you can tell the system to always load the ecryptfs module.

To me, this looks like a bug.

[Gleixner (gleixner)]

If you read the comments in the source:
http://bazaar.launchpad.net/~ecryptfs/ecryptfs/ecryptfs-utils/view/head:/src/utils/mount.ecryptfs_private.c
starting from line 304, it says that suid is needed for this executable. It also says, what actions are performed as superuser. Module loading is not performed. I guess module loading is made by "mount -t ecryptfs" but it is maybe incomplete because it has to load additional modules. In my case the md5 is missing:

flo@mamba:~> diff lsmod_before lsmod_1st_try
1a2,11
> ecb 12863 1
> ecryptfs 113255 1
> cbc 12880 0
> sha256_generic 21031 2
> encrypted 18148 1 ecryptfs
> ecryptfs_format 13013 1 encrypted
> sha1_generic 12679 2
> trusted 21890 1 encrypted
> tpm 26915 1 trusted
> tpm_bios 13683 1 tpm
flo@mamba:~> diff lsmod_1st_try lsmod_2nd_try
1a2
> md5 12627 0

[Nrickert (nrickert)]

There's another relatively minor bug with ecryptfs. I'm putting it here, though perhaps it should be a different bug report.

When you run "ecryptfs-setup-private" to setup ecryptfs for the logged in user, it creates a directory $HOME/Private on top of which the encrypted data can be mounted.

When the encrypted data is not mounted, that directory contains 2 symlinks:

Access-Your-Private-Data.desktop -> /usr/share/ecryptfs-utils/ecryptfs-mount-private.desktop
README.txt -> /usr/share/ecryptfs-utils/ecryptfs-mount-private.txt

The second of those symlinks is fine. But the first symlink is broken; the destination ".desktop" file does not exist. Somebody probably forgot to generate it for the distro.

[Darin (darinp)]

(In reply to comment #1)
> the package maintainer has not requested a setuid bit by default so far so the
> program is not audited whether it's actually safe to set it.

Per Security_packaging_policy#Setuid_binaries, only a bug report needs to be submitted to the security team, there's no mention that the maintainer need be the submitter.

Given this, can we conclude that this bug report fulfills point #1 and Point #2, is fulfilled by Comment #3 of the bug report where on beginning on line #304 of the source code documents why /sbin/mount.ecryptfs_private need to setuid?

http://en.opensuse.org/openSUSE:Security_packaging_policy#Setuid_binaries

[Meissner-i (meissner-i)]

i will make the package ready, but we need to review it first too

[Marcus Meissner (meissner)]

incremental, do not use 64 groups fixed but NGROUPS_MAX from limits.h

[Meissner-i (meissner-i)]

Created an attachment (id=497615)
ecryptfs-utils-security.patch

with sysconf()

[Marcus Meissner (meissner)]

3rd incremental, again gorup allocation changed to use sysconf() as NGROUSP_MAX is just 8.

[Meissner-i (meissner-i)]

I will be adding setuid root 4755 to permissions in permissions.easy mode.

[Meissner-i (meissner-i)]

all submitted for factory and 12.2

hmm, not sure if we should do this for 12.1 retroactively.

[Bwiedemann (bwiedemann)]

This is an autogenerated message for OBS integration:
This bug (740110) was mentioned in
https://build.opensuse.org/request/show/127291 Factory / permissions

[Tyler Hicks (tyhicks)]

Hi Marcus and Sebastian - Thanks for the patch!

It fixes some issues that were previously reported in a private bug report. I started work on fixing those issues and then, unfortunately, allowed the patches to bit rot for far too long.

I'm taking a look at the differences in Sebastian's patch and my set of patches and I'll respond again after that is complete.

[F-krahmer (f-krahmer)]

Upstream acked the existence of MS_NODEV and MS_NOSUID weakness.
Seems we need to add MS_NODEV too, so the old update needs to be dropped.

[F-krahmer (f-krahmer)]

Created an attachment (id=498115)
security patch, also using MS_NODEV

[Tyler Hicks (tyhicks)]

I've committed Sebastian's patch because it is more complete than what I had. Thanks again!

[Meissner-i (meissner-i)]

linked launchpad bug

https://bugs.launchpad.net/ecryptfs/+bug/1020904

[Marcus Meissner (meissner)]

we have one more adjusment

ecryptfs-utils-96.orig/src/utils/mount.ecryptfs_private.c

- if (mount(src, ".", FSTYPE, 0, opt) == 0) {
+ if (mount(src, ".", FSTYPE, MS_NOSUID|MS_NODEV, opt) == 0) {

So pass in both MS_NOSUID and MS_NODEV just for the chance that someone tries to put a setuid binary or device node under us.

[Darin (darinp)]

(In reply to comment #25)
> all submitted for factory and 12.2
>
>
> hmm, not sure if we should do this for 12.1 retroactively.

I'm curious to know why this wouldn't be applied retroactively for 12.1? OpenSuSE 12.1 was only released on 2011-11-16, per the release notes, and will be available for general consumption for 24 months from the release date give the current release cycle. One could also argue these changes should be applied to 11.4 since it will be available until March 2013. Additionally, given the issues related to the release of 12.2, I think it's safe to say that 12.1 is the primary distribution being used by most users so these enhancements aught to benefit them.

[Andreas Jaeger (jaegerandi)]

Darin, it's not 2 years. It's 18 months (or more accurate two releases plus two months), 11.4 will be unmaintained two months after 12.2 is out...

http://en.opensuse.org/Lifetime

[Meissner-i (meissner-i)]

aj, nethertheless we could post this to 11.4 and 12.1 once the shaking out bugs has stopped

[Andreas Jaeger (jaegerandi)]

Marcus, sure. Getting this out for 12.1 and 11.4 is fine. But I agree, let's give this some more testing first...

[Nrickert (nrickert)]

I am testing these changes in 12.2 RC1. Unfortunately, they don't work.

"ecryptfs-mount-private" works

However, automatic mounting of the private directory on login does not work.

Comparing the pam setup that I had working in 12.1, here is the change that I had to make to get it to work:

--- common-auth-pc 2012/07/13 14:20:58 1.1
+++ common-auth-pc 2012/07/13 14:20:30
@@ -11,7 +11,7 @@
 # (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the
 # traditional Unix authentication mechanisms.
 #
-auth required pam_ecryptfs.so unwrap
 auth required pam_env.so
 auth optional pam_gnome_keyring.so
 auth required pam_unix2.so
+auth required pam_ecryptfs.so unwrap

In other words, making that "pam_ecryptfs.so" line the last entry rather than the first fixes the problem. Presumably, something that is done in the other pam calls is prerequisite for ecryptfs to work.

The unmounting at end of session does work okay.

[Meissner-i (meissner-i)]

so pam-config needs to learn to append it after unix2 I guess

[Meissner-i (meissner-i)]

Torsten, pam-config ... ecryptfs needs to be moved behindthe password inputting PAM auth modules ... I am a bit afraid to touch supported-modules.h though, due the scary krb5 comment ;)

[Tyler Hicks (tyhicks)]

Note that shortly after ecryptfs-utils-99 was released, a regression was identified in the fix for this bug. It is being tracked as bug #1024476.

[Meissner-i (meissner-i)]

https://bugs.launchpad.net/ecryptfs/+bug/1024476

I think our PAM module changes might be too strict, as the ecrytpfs kernel module is not autoloaded anymore. (unclear if it is related)

[Tyler Hicks (tyhicks)]

Released in ecryptfs-utils-99

[Kukuk-g (kukuk-g)]

I moved it now after pam_unix2.so in the stack. But this means that pam_ecryptfs will not work together with kerberos/ldap. But at least it will work for some people.

[Bwiedemann (bwiedemann)]

This is an autogenerated message for OBS integration:
This bug (740110) was mentioned in
https://build.opensuse.org/request/show/130306 Factory / pam-config

[Kukuk-g (kukuk-g)]

I have no idea for pam_ecryptfs and ldap/kerberos...