5

I found this answer on learning Linux Kernel Programming and my question is more specific for the security features of the Linux Kernel. I want to know how to limit privileged users or process's access rights to other processes and files in contrast to full access of root.

Until now I found:

  • user and group for Discretionary Access Control (DAC), with differentiation in read, write and execute for user, group and other
  • user root for higher privileged tasks
  • setuid and setgid to extend users's DAC and set group/user ID of calling process, e.g. user run ping with root rights to open Linux sockets
  • Capabilities for fine-grained rights, e.g. remove suid bit of ping and set cap_net_raw
  • Control Groups (Cgroups) to limit access on resources i.e. cpu, network, io devices
  • Namespace to separate process's view on IPC, network, filesystem, pid
  • Secure Computing (Seccomp) to limit system calls
  • Linux Security Modules (LSM) to add additional security features like Mandatory Access Control, e.g. SELinux with Type Enforcement

Is the list complete? While writing the question I found fanotify to monitor filesystem events e.g. for anti virus scans. Probably there are more security features available.

Are there any more Linux security features which could be used in a programmable way from inside or outside of a file or process to limit privileged access? Perhaps there is a complete list.

Community
  • 1
  • 1
admirableadmin
  • 2,669
  • 1
  • 24
  • 41
  • 2
    Read [credentials(7)](http://man7.org/linux/man-pages/man7/credentials.7.html) & [capabilities(7)](http://man7.org/linux/man-pages/man7/capabilities.7.html) & [namespaces(7)](http://man7.org/linux/man-pages/man7/namespaces.7.html) & [xattr(7)](http://man7.org/linux/man-pages/man7/xattr.7.html) – Basile Starynkevitch Jun 17 '15 at 09:08

2 Answers2

2

The traditional unix way to limit a process that somehow needs more privileges and yet contain it so that it cannot use more than what it needs is to "chroot" it.

chroot changes the apparent root of a process. If done right, it can only access those resources inside that newly created chroot environment (aka. chroot jail) e.g. it can only access those files, but also, only those devices etc.

To create a process that does this willingly is relatively easy, and not that uncommon.

To create an environment where an existing piece of software (e.g. a webserver, mailserver, ...) feels at home in and still functions properly is something that requires experience. The main thing is to find the minimal set of resources needed (shared libraries, configuration files, devices, dependent services (e.g. syslog), ... ).

  • Hi, a chroot environment does not limit kernel access. If a process inside a chroot require privileged access i.e. to open privileged ports < 1024 (in your example this is the case for a webserver), so the chroot will run with root privileges, which helps to break out of the jail. See http://unixwiz.net/techtips/chroot-practices.html – admirableadmin Aug 24 '15 at 07:25
  • in case of the webserver: run it in the chroot on another port if that's what you need and worst case you can use a packet filter or firewall to redirect ports 80 and 443 to it. But I agree it's not limiting access to the kernel. If software is however written for this, it can leave most if not all of its files outside of the chroot environment, then drop privileges, and then do the chroot procedure itself. That way you only have normal user privileges and e.g. no stray devices, binaries, libraries etc inside the chroot environment. –  Aug 24 '15 at 23:48
-2

You may add EFS,AppArmor,Yama auditctl,ausearch,aureport Tools similar to fanotify: Snort, ClamAV,OpenSSL,AIDE, nmap, GnuPG

Sheetal Angra
  • 57
  • 4
  • Hi, my question is about limiting priv. user access at the kernel, but not about encryption (EFS, OpenSSL, GnuPG) or intrusion detection and network security (AIDE, Snort, nmap). AppArmor and Yama are also provided by LSM. auditctl,ausearch,aureport are also used by SELinux. – admirableadmin Aug 22 '15 at 14:06