LSS-NA 2019 Note: Tutorial - How to Write a Linux Security Module

lss-na-2019.lsm-tutorial-note.md

LSS-NA 2019 Day 3 Tutorial: How to Write a Linux Security Module

This is the note I have taken during the tutorial session "How to Write a Linux Security Module" by Casey Schaufler, at the Linux Security Summit North America 2019.

• Why do you want to write a Linux security module?

• When is Linux security module the right choice?

  • Add access control restrictions
  • Things controlled by the kernel
  • Mandatory access control

• When is LSM the wrong choice?

  • Change access control restrictions
  • Readily done in user space

• Alternatives to LSM

  • Special purpose filesystems
  • Namespaces
  • Seccomp
  • Netfilter
  • BPF

• Security module don'ts

  • Duplicate and existing module
  • Block waiting on user space helpers
  • Inflame the community

Design your LSM

• Think about what you want to protect

  • Objects
  • Pathnames
  • Processes
  • Hunks of data
  • Resources

• What do you want to protect it from?

  • Users: malicious - stupid
  • Applications
  • Network access

• The hooks and blobs of a LSM

  • inode_permission <-> security_inode_permission <-> sample_inode_permission <-> inode->i_security

• Access control hooks

  • Passed relevant pointers
  • (Usually) in current context
  • Use any needed
  • Return access decision

• Hooks are bail on fail

  • First error encountered is returned
  • State engines beware

• State maintenance hooks

  • Allocate or initialize blobs
  • Update data in blobs
  • Tear down or free blobs
  • Secid and context mapping

• Access hooks return values

  • 0
  • ENOMEM
  • EACCES
  • EPERM

• Security Blobs

  • Referenced from kernel data structures
  • Managed by the infrastructure
  • Or by the module in some cases

• Module details DEFINE_LSM(sample) = { .name = , .flags = , .blobs = , .init = , };

• The blob, the secid and the secctx

• Lifecycle management of a secctx

  • sample_secctx_to_secid
  • sample_secid_to_secctx
  • sample_release_secctx

  Callers will always use security_release_secctx

• Process attributes

  • Credentials
    • Credentials are shared
    • Copy on write
    • Managed by infrastructure
  • Tasks
    • Basic unit of execution
    • Infrastructure managed
  • /proc/<pid>/attr
    • Defined in procfs
    • Writable if pid == "self"
    • Don't reuse entries
    • Use a subdirectory

• Object based hooks

  • Affiliated with kernel objects
  • Access based on attributes attached tot he object
  • May be difficult for a human to identify

• Traditional file security attributes

  • Don't overload attributes

• Extended attributes

• IPC objects and keys

• CONFIG_SECURITY_PATH (John Johansen)

  • Aliases are the real problem to deal with path
    • Symlinks (easiest)
      • 2 objects: symlink and target
      • d_path...: post symlink traversal; mediation of target
    • Hardlinks (harder)
      • Permanent alias
      • Does creating link
    • Mounts
      • Runtime
      • Mount mediation hooks
    • Chroots
      • d_absolute_path()
    • Mount namespaces (real killer)

• Networking (by Paul Moore)

  • Network hooks
    • Socket level hooks
    • Packet level hooks
      • access control between packets and the interfaces/sockets/etc
    • Network Labels - secmark
      • Packet labels set using netfilter
      • Labels based on local configuration, not remote security attributes
      • The networking equivalent of the "context mount"
    • Network Labels - NetLabel
    • Network Labels - labeled IPsec
    • SO_PEERSEC and IP_PASSSEC
  • Hidden Dangers - accept(2)
    • too late to reject connections
    • Use the per-packet access control hooks instead
  • Hidden Dangers - struct sk_buff
  • Hidden Dangers - Label protocols

• Audit

  • Audit vs traditional logging
    • Audit intended for "security relevant" events
    • Developed for security certification efforts
  • Audit events
    • Audit "records" make up an audit "event"
    • Audit subsystem handles bundling of records
  • What to audit
    • access control decisions
    • configuration changes
    • be careful not to flood the audit logs
  • How to audit
    • Don't change the order of fields in a record
    • Use existing field names when possible
    • security/lsm_audit.c for common tasks
    • cc: linux-audit@redhat.com
    • Write test cases: github.com/linux-audit/audit-testsuite

• Security Module Interfaces

  • Module configuration mechanisms
    • Avoid syscall, prctl, fcntl, ioctl
    • Use securityfs, sysfs
  • Adding New Hooks
    • Make an existing hook more general: pass &thing, not &thing.security
  • Boot line
    • security=selinux: compatibility
    • lsm=loadpin,yama,selinux: complete specs
    • lsm.debug: startup information

• Wrap up

  • Have a good reason for LSM
    • Do something useful
    • Do something the kernel can and should do
    • Follow up with user space support and documentation
  • Don't reinvent the wheel
    • Show something new
    • Time based controls have not been done (albeit being attempted)
    • Location controls could be fun
    • Security doesn't have to be dull