Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pam_zfs_key: Add SELinux policy for PAM module #13271

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ColMelvin
Copy link
Contributor

@ColMelvin ColMelvin commented Mar 30, 2022

Motivation and Context

On a system running with SELinux enforcing, pam_zfs_key can be denied the access it needs. While this doesn't affect unconfined processes (as sudo -u and su commonly would be), targeted processes (like sshd) are unable to unlock (or even find) the user's dataset.

Description

This pull request adds a loadable SELinux policy module to the repository, allowing systems using SELinux to make full use of the PAM module. The module adds as few permissions as possible to keep the attack surface small, thus maintaining the benefits of using SELinux.

How Has This Been Tested?

  1. Installed and configured PAM module on system
  2. Created new user with encrypted home dataset (but not under /home, for easier testing)
  3. Unloaded key for encrypted home dataset and logged out of all user sessions
  4. SSH into box as user with encrypted home dataset using password authentication
  5. Checked keystatus for encrypted home dataset and found it unavailable
  6. Installed SELinux policy module
  7. Logged out of SSH session
  8. SSH into box as user with encrypted home dataset using pasword authentication
  9. Checked keystatus for encrypted home dataset and found it available
  10. Changed password using passwd
  11. Logged out of SSH session
  12. Logged into system as another user and checked keystatus for encrypted home dataset; found it unavailable
  13. SSH into box as user with encrypted home dataset using new pasword authentication
  14. Checked keystatus for encrypted home dataset and found it available

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Performance enhancement (non-breaking change which improves efficiency)
  • Code cleanup (non-breaking change which makes code smaller or more readable)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
  • Documentation (a change to man pages or other documentation)

Checklist:

@ColMelvin
Copy link
Contributor Author

ColMelvin commented Mar 30, 2022

I created this SELinux policy module in a separate project for my own uses and am now looking to integrate it into upstream. I seek advice on how best to add this feature to the repository so that it can be consumed. In particular,

  1. Should the code get added as a sub-package to the existing rpm/generic/zfs.spec.in file or should a new RPM be created?
  2. Should the SELinux module have the same version as ZFS, same version as pam_zfs_key, or its own separate version?
  3. What's the best way to document usage?

Additionally, I would appreciate advice from anyone familiar with SELinux and a security review. I would like to create a separate label for /dev/zfs for added security, but I'm unsure how (or if) doing so would impact existing deployments.

type device_t;
')

dnl Using ifdef() keeps `sepolgen-ifgen' from complaining
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only systems with SELinuxProject/selinux#348 applied will actually find this comment to be accurate.

@behlendorf behlendorf added the Status: Work in Progress Not yet ready for general review label Mar 30, 2022
Provide a policy that allows pam_zfs_key to work on an SELinux protected
system without giving excessive access to the PAM module.  This way, any
exploited application using PAM remains unable to destroy datasets or do
anything similarly damaging.

Alas, libzfs opens the device with both read & write permissions, so any
policy that doesn't label the /dev/zfs device specially could open up
other devices to be exploited.  Unfortunately, relabeling the device has
the potential to impact existing systems, so it is not part of this
commit.

Signed-off-by: Chris Lindee <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Work in Progress Not yet ready for general review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants