Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Making the LSM available to containers

Making the LSM available to containers

Containers would like to be able to make use of Linux Security Modules (LSMs), from providing more complete system virtualization to improving container confinement. To date containers access to the LSM has been limited but there has been work to change the situation.

This presentation will discuss the current state of LSM stacking and namespacing. The work being done on various security modules to support namespacing, the infrastructure work being done to improve the LSM, an examination of the remaining problems, and provide a demo of a container leveraging LSM stacking so that the host is using a different security module than that of the container.

jrjohansen

May 26, 2018
Tweet

More Decks by jrjohansen

Other Decks in Programming

Transcript

  1. Linux Security Modules (LSM) • Infrastructure to provide security –

    Abstract security policy from the rest of the kernel – Module provides policy and mechanism – Often MAC but not necessarily • selinux, smack, apparmor, tomoyo, IMA/EVM, loadpin, yama • proposed: LSMs: LandLock, CaitSith, Checmate, HardChroot, PTAGS, SimpleFlow, SafeName, WhiteEgret, shebang, S.A.R.A.
  2. Why? • System Container – Needs to be able to

    select LSM – Needs to be able to load guest policy • App container – sandboxing – eg. snappy
  3. dentry = kern_path_create(AT_FDCWD, sun_path, &path, 0); err = PTR_ERR(dentry); if

    (IS_ERR(dentry)) return err; /* * All right, let's create it. */ err = security_path_mknod(&path, dentry, mode, 0); if (!err) { err = vfs_mknod(d_inode(path.dentry), dentry, mode, 0); if (!err) { res->mnt = mntget(path.mnt); res->dentry = dget(dentry); } }
  4. Security blobs • cred • task • Inode • file

    • superblock • ... #ifdef CONFIG_FS_POSIX_ACL struct posix_acl *i_acl; struct posix_acl *i_default_acl; #endif const struct inode_operations *i_op; struct super_block *i_sb; struct address_space *i_mapping; #ifdef CONFIG_SECURITY void *i_security; #endif /* Stat data, not accessed from path walking */ unsigned long i_ino;
  5. static struct security_hook_list selinux_hooks[] __lsm_ro_after_init = { LSM_HOOK_INIT(binder_set_context_mgr, selinux_binder_set_context_mgr), LSM_HOOK_INIT(binder_transaction,

    selinux_binder_transaction), LSM_HOOK_INIT(binder_transfer_binder, selinux_binder_transfer_binder), LSM_HOOK_INIT(binder_transfer_file, selinux_binder_transfer_file), LSM_HOOK_INIT(ptrace_access_check, selinux_ptrace_access_check), LSM_HOOK_INIT(ptrace_traceme, selinux_ptrace_traceme), LSM_HOOK_INIT(capget, selinux_capget), LSM_HOOK_INIT(capset, selinux_capset), LSM_HOOK_INIT(capable, selinux_capable), LSM_HOOK_INIT(quotactl, selinux_quotactl), LSM_HOOK_INIT(quota_on, selinux_quota_on), LSM_HOOK_INIT(syslog, selinux_syslog), ... Module functions
  6. Minor LSM Stacking • Landed in 4.2 • list of

    functions for each hook • Single security blob • 1 major module – Uses security blob – Uses shared interfaces • No limit on minor module
  7. Blob management #ifdef CONFIG_FS_POSIX_ACL struct posix_acl *i_acl; struct posix_acl *i_default_acl;

    #endif const struct inode_operations *i_op; struct super_block *i_sb; struct address_space *i_mapping; #ifdef CONFIG_SECURITY void *i_security; #endif /* Stat data, not accessed from path walking */ unsigned long i_ino; selinux_security apparmor_security smack_security yama_security
  8. secids management • 32 bit integer • Every LSM uses

    it a little diferent • Global • No lifetime management • Part of some LSMs policy • Would like a void *security
  9. secids management • 32 bit integer • Every LSM uses

    it a little diferent • Global • No lifetime management • Part of some LSMs policy • Would like a void *security – can’t have it
  10. secids management • Like security blobs LSM takes over management

    – Just not as clean – Currently still has lifetime issues
  11. Fix • New versions of interfaces – /proc/pid/attr/selinux/* – /proc/<pid>/attr/smack/*

    – ... Problem – Sharing Interfaces Problem • Userspace Interfaces – /proc/pid/attr/* – SO_PEERSEC
  12. Fix • New versions of interfaces – /proc/pid/attr/selinux/* – /proc/<pid>/attr/smack/*

    – ... • Virtualize – per task default – Interface uses task default Problem – Sharing Interfaces Problem • Userspace Interfaces – /proc/pid/attr/* – SO_PEERSEC
  13. Fix • Extend support to multiple LSMs • Either extend

    to either – support selecting LSM – set default LSM for net NS • Setting a secmark – sets respective LSM mark • Update LSM hooks to allow them to compose if needed • Still working on the others Problem continued Problem • Networking – secmark
  14. Fix • Either – Allow a single LSM to claim/use

    packet labeling – Every LSM packet label must agree (be the same) Problem continued Problem • Networking – Secmark – Packet labeling • cipso • calypso • xfrm
  15. The LSMs are working on it IMA • Patches to

    NS IMA policy • RFC patches to NS IMA audit • WIP: patches to NS interfaces SeLinux • Discussing/Designing namespacing • Patches to refactor/remove global state Smack • patches to label namespaces • Per process rules Audit • wip to support namespaces – Audit ids – ptags • Layering issues
  16. The LSMs are working on it AppArmor • Policy namespaces

    • Virtualized interfaces • Internal stacking
  17. 95% there • LSMs do things diferently • No consensus

    – On what it means to be a container – On how containers should interface to LSM namespaces • Attributes (ie. xattrs) need to be namespaced • Need some new hooks around system namespaces
  18. Special thanks Casey Schaufer – LSM Stacking AppArmor developers IMA

    developers Smack developers Selinux developers LXD developers
  19. License This slide deck is licensed under the Creative Commons

    Attribution-ShareAlike 4.0 International license. It can be shared and adapted for any purpose (even commercially) as long as Attribution is given and any derivative work is distributed under the same license. Details can be found at https://creativecommons.org/licenses/by-sa/4.0/ General Disclaimer This document is not to be construed as a promise by any participating organisation to develop, deliver, or market a product. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. openSUSE makes no representations or warranties with respect to the contents of this document, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. The development, release, and timing of features or functionality described for openSUSE products remains at the sole discretion of openSUSE. Further, openSUSE reserves the right to revise this document and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. All openSUSE marks referenced in this presentation are trademarks or registered trademarks of SUSE LLC, in the United States and other countries. All third-party trademarks are the property of their respective owners. Credits Template Richard Brown [email protected] Design & Inspiration openSUSE Design Team http://opensuse.github.io/branding- guidelines/