Enhanced Trusted Path Execution (TPE) Linux Security Module
Subsystems (2)
PATCH 1/1 Enhanced Trusted Path Execution (TPE) Linux Security Module
Hi,
This patch adds support for an enhanced Trusted Path Execution (TPE) subsystem relying in the Linux Security Modules framework. It's a rewrite of the IBM's TPE LSM module by Niki A. Rahimi, which adds a couple of improvements and feature enhancements.
The most notable of them are support for per-gid basis access control lists in runtime and kernel-configuration time (adds support for trusted and untrusted user groups), procfs interface for statistics and runtime information and debugging capabilities (for limiting the garbage messages).
Also, the documentation has been rewritten and under the "Trusted Path Execution (EXPERIMENTAL)" configuration option, has been added a "GID for trusted users" key to make possible to set a default gid for a specific trusted user group.
The reasons that give sense for including this, are that standard Vanilla kernels have SELinux and LSM (SELinux already supports TPE functionalities), but SELinux has less possibilities of being used by those desktop or just not experienced users who are not already using their distribution-specific SELinux implementation, even if they want simple protections for their every-day system use, also, the availability of some patch-sets with security enhancements (like grsecurity) distracts users of being using the LSM framework or even SELinux itself, in addition, this TPE has more features than grsecurity's one in terms of per-users and groups acl basis, which make easy the management of the TPE protection.
In short, after a first review you can see that it could worthy to include this in the kernel sources.
Note: the code, as it is right now, has some limitations that would be solved in a relatively short time manner, more short if more people contribute to it.
The limitations of the current code are described
in ./Documentation/tpe-lsm.txt
Patch against 2.6.10 attached.
(not inside msg body for preventing messing up by archives-managing software)
I will make available an independent-packaged version ASAP, which could be built outside the kernel sources, at http://selinux.tuxedo-es.org
Cheers,
PS: I would appreciate to be CC'ed, as I'm not subscribed to the list. (Just for mail traffic volume reasons, which i don't have time to handle)
Signature · 2 lines
Lorenzo Hernández García-Hierro <[email protected]> [1024D/6F2B2DEC] [2048g/9AE91A22] Hardened Debian head developer & project manager
Documentation/tpe-lsm.txt renamed from linux-2.6.10/Documentation/tpe-lsm.txt +89 -0
@@ -0,0 +1,89 @@ +Trusted Path Execution Linux Security Module +Copyright (C) 2003 IBM Corp. <[email protected]> +Copyright (C) 2005 Lorenzo Hernandez Garcia-Hierro <[email protected]> +Author: Lorenzo Hernández Garcia-Hierro (Original: Niki Rahimi) +This file is distributed according to the GNU General Public License. +This module was tested on the Linux kernel 2.6.9 and 2.6.10. + +The purpose of the Trusted Path Execution Linux Security Module is to enable a +check in the Linux kernel to limit the running of executables in trusted paths +so that the potential for malicious code to be run on the system is reduced. +A trusted path is one in which the parent directory of a file is owned by root +and is neither group nor other writeable. +The module relies on a kernel hook which checks to see if the given path is +trusted or not and who is the user (or group member) that caused the event (execution). +This check takes place directly upon an attempt to execute the code by using the +bprm_set_security hook. + +Limitations: Right now, the engine does not use the bprm_secureexec hook to +prevent use of sensitive LD_* variables by untrusted users or groups, also it +does not use mmap nor mprotect LSM hooks that could prevent bypass of the +bprm_set_security checks, as commented by Stephen S. Smalley <[email protected]>. +This features would be developed ASAP, but it's not a critical, blocking issue. + +The module also creates two Trusted Path access control lists which can be accessed +by a sysfs mountpoint, inside the ./tpefs/ subdir (ie: /sys/tpefs), writeable by root, +who can add and delete uids (user id's) and a entire range of users using the (new) native +support for per-gid (group id) basis access control lists. A user on the list is +considered trusted. +Also, it creates a procfs entry called "tpe" (ie: /proc/tpe) which provides +version information, total amount of trusted users, total amount of trusted groups and +other information, depending on the code revision), and those who want extra garbage +from the kernel will like to enabled debugging by passing debug=1 to the module parameters. +By default, root is hard coded onto this list with also a trusted gid +which gets automatically added when selecting the "GID for trusted users" option in kernel +configuration (SECURITY_TPE_TRUSTED_GID). + +Thus if user A attempts to run an executable in path A, the following scenarios +can play out: + +1. Trusted user,trusted path = User is able to run the executable. +2. Trusted user,trusted path,trusted group = User is able to run the executable. +3. Trusted user,untrusted path = User is able to run the executable. +4. Trusted user,untrusted path,trusted group = User is able to run the executable. +5. Trusted user,untrusted path,untrusted group = User is able to run the executable. +6. Untrusted user,trusted path = User is able to run the executable. +7. Untrusted user,trusted path,trusted group = User is able to run the executable. +8. Untrusted user,trusted path,untrusted group = User is able to run the executable. +9. Untrusted user,untrusted path = User is not able to run the executable.# +10. Untrusted user,untrusted path,trusted group = User is able to run the executable. +11. Untrusted user,untrusted path,untrusted group= User is not able to run the executable.# + +In short, if the path and user are both untrusted (and also if the group +is untrusted), execution will be denied sending a message with the uid,gid, +euid,egid,pid and binary that caused the event. + +In order to actually modify the access control list for TPE, the module uses +a sysfs subsystem called tpefs. The tpefs contains four files; add, del, add-group +and del-group. +Performing read and write operations on the aforementioned files creates a user +to system interface that will alter the TPE access control list. See +"Modifying the TPE Access Control Lists" below for the methods of altering the list +using these files. +Note: The original two file approach was utilized rather than a single file in order to +keep the code and administration of the module simple for both the kernel and +the user, and it was when only uid-based access control lists were supported, now +i've followed the same style to provide backwards compatibility. + +Installation: +1. Recompile the kernel to include LSM and TPE as a module (or even get a + kernel-independent packaged TPE module. +2. mount -t sysfs sysfs <mountpoint> +3. modprobe tpe debug=1/0 (if you want to use debugging set to 1) +4. See "Modifying the TPE Access Control Lists" below for instructions on how to +add/delete users and groups to/from the list. + +Modifying the TPE Access Control Lists: + +- Adding a user : echo <uid> > <mountpoint>/tpefs/add +- Deleting a user : echo <uid> > <mountpoint>/tpefs/del +- Adding a group : echo <gid> > <mountpoint>/tpefs/add-group +- Deleting a group : echo <gid> > <mountpoint>/tpefs/del-group +- Show uid list to userspace: cat <mountpoint>/tpefs/add +- Show gid list to userspace: cat <mountpoint>/tpefs/add-group +- Show version and statistics information: cat /proc/tpe + +Note: Advanced users would be interested in writing a script or something +to modify the access control lists in a fine-grained manner, but this is out +of the goals of the TPE development, anyway, feel free to send your contributions +to [email protected].
security/Kconfig renamed from linux-2.6.10/security/Kconfig +31 -0
@@ -84,6 +84,37 @@ If you are unsure how to answer this question, answer N. +config SECURITY_TPE + tristate "Trusted Path Execution (EXPERIMENTAL)" + depends on SECURITY && EXPERIMENTAL + help + The TPE module enforces a check on the running of executables. + It will not allow execution if the program is located in a + "trusted path" and the current user is "untrusted". A trusted + path is one which is root owned and neither group nor other + writeable. An user is considered trusted if their uid is added + to a trusted list in memory, also, user groups can be trusted + in kernel compile-time and runtime by adding them to the gid-basis + access control list.Root is trusted, by default.A proc interface + /proc/tpe is created when module loads, it shows version and ACL + information to use third-party checkers or scripts. + Original code for 2.5.59 by Niki A. Rahimi <[email protected]>. + + (c) 2005, Lorenzo Hernandez Garcia-Hierro <[email protected]>. + + Read ./Documentation/tpe-lsm.txt for more information. + If you are unsure how to answer this question, answer N. + +config SECURITY_TPE_TRUSTED_GID + int "GID for trusted users" + depends on SECURITY_TPE + default 1337 + help + Users with the primary group id given here will not be subject to the + trusted path restrictions by default. These users will therefore + represent a security risk to themselves and potentially to the system. + Please be sure that you can trust the members of this group. + source security/selinux/Kconfig endmenu
security/Makefile renamed from linux-2.6.10/security/Makefile +1 -0
@@ -17,3 +17,4 @@ obj-$(CONFIG_SECURITY_CAPABILITIES) += commoncap.o capability.o obj-$(CONFIG_SECURITY_ROOTPLUG) += commoncap.o root_plug.o obj-$(CONFIG_SECURITY_SECLVL) += seclvl.o +obj-$(CONFIG_SECURITY_TPE) += tpe.o
security/tpe.c renamed from linux-2.6.10/security/tpe.c +624 -0
624 lines not on this page · raw message
security/tpe.h renamed from linux-2.6.10/security/tpe.h +155 -0
155 lines not on this page · raw message
Quoted 4 lines · * Lorenzo Hernández García-Hierro ([email protected]) wrote:
This patch adds support for an enhanced Trusted Path Execution (TPE) subsystem relying in the Linux Security Modules framework. It's a rewrite of the IBM's TPE LSM module by Niki A. Rahimi, which adds a couple of improvements and feature enhancements.
Thanks for taking interest and working on this.
Quoted 5 lines
The most notable of them are support for per-gid basis access control lists in runtime and kernel-configuration time (adds support for trusted and untrusted user groups), procfs interface for statistics and runtime information and debugging capabilities (for limiting the garbage messages).
How does per-gid help in this case (esp. the desktop scenario you mentioned)? And the /proc/tpe file might as well go under sysfs with the rest of the other entries instead of cluttering /proc.
Quoted 5 lines
The reasons that give sense for including this, are that standard Vanilla kernels have SELinux and LSM (SELinux already supports TPE functionalities), but SELinux has less possibilities of being used by those desktop or just not experienced users who are not already using their distribution-specific SELinux implementation, even if they want
Quoted 8 lines
simple protections for their every-day system use, also, the availability of some patch-sets with security enhancements (like grsecurity) distracts users of being using the LSM framework or even SELinux itself, in addition, this TPE has more features than grsecurity's one in terms of per-users and groups acl basis, which make easy the management of the TPE protection.
In short, after a first review you can see that it could worthy to include this in the kernel sources.
The two biggest issues are 1) it's trivial to bypass:
$ /lib/ld.so /untrusted/path/to/program and 2) that there's no (visible/vocal) user base calling for the feature.
So working those issues will help make a better case for mainline inclusion.
thanks,
-chris
Signature · 1 line
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Quoted 7 lines · Chris Wright
Quoted 4 lines · * Lorenzo Hernández García-Hierro ([email protected]) wrote:
This patch adds support for an enhanced Trusted Path Execution (TPE) subsystem relying in the Linux Security Modules framework. It's a rewrite of the IBM's TPE LSM module by Niki A. Rahimi, which adds a couple of improvements and feature enhancements.
Thanks for taking interest and working on this.
NP, this is just for fun and maybe for doing something useful for others.
Quoted 9 lines
Quoted 5 lines
The most notable of them are support for per-gid basis access control lists in runtime and kernel-configuration time (adds support for trusted and untrusted user groups), procfs interface for statistics and runtime information and debugging capabilities (for limiting the garbage messages).
How does per-gid help in this case (esp. the desktop scenario you mentioned)? And the
/proc/tpefile might as well go under sysfs with the rest of the other entries instead of cluttering /proc.
It helps if you are going to trust a whole group of users. The procfs entry goes inside proc to make it clearly accessible for the immediate users, and /proc, in my opinion, is the legacy interface for such type of things (even the input can not be handled as a sysctl as grsec's tpe does, because we handle complete acl's and not just one trusted group nor user).
Anyway, if i must do it i will do it, it's not a problem (i think so).
Quoted 14 lines
Quoted 5 lines
The reasons that give sense for including this, are that standard Vanilla kernels have SELinux and LSM (SELinux already supports TPE functionalities), but SELinux has less possibilities of being used by those desktop or just not experienced users who are not already using their distribution-specific SELinux implementation, even if they want
Quoted 8 lines
simple protections for their every-day system use, also, the availability of some patch-sets with security enhancements (like grsecurity) distracts users of being using the LSM framework or even SELinux itself, in addition, this TPE has more features than grsecurity's one in terms of per-users and groups acl basis, which make easy the management of the TPE protection.
In short, after a first review you can see that it could worthy to include this in the kernel sources.
Quoted 3 lines
The two biggest issues are 1) it's trivial to bypass:
$ /lib/ld.so /untrusted/path/to/program and 2) that there's no (visible/vocal) user base calling for the feature.
About the point 1), yesterday i wrote just a simple regression test (that can be found at the same place as the patch) and of course it bypasses, this is an old commented problem, Stephen suggested the use of the mmap and mprotect hooks, so, i will have a look at them but i'm not sure on how to (really) prevent the dirty,old trick.
About 2), just give it a chance, maybe it's useful and my work is not completely nonsense.
Quoted 2 lines
So working those issues will help make a better case for mainline inclusion.
OK, i will try to work on them but i can't promise, this is my second month playing around with kernel hacking (and almost C programming), so, i'll need one or two nights to see how to get it ;-)
Thanks for the comments and your attention,
Cheers.
Signature · 2 lines
Lorenzo Hernández García-Hierro <[email protected]> [1024D/6F2B2DEC] [2048g/9AE91A22] Hardened Debian head developer & project manager
Quoted 11 lines · Lorenzo Hernández García-Hierro
Quoted 3 lines
The two biggest issues are 1) it's trivial to bypass:
$ /lib/ld.so /untrusted/path/to/program and 2) that there's no (visible/vocal) user base calling for the feature.About the point 1), yesterday i wrote just a simple regression test (that can be found at the same place as the patch) and of course it bypasses, this is an old commented problem, Stephen suggested the use of the mmap and mprotect hooks, so, i will have a look at them but i'm not sure on how to (really) prevent the dirty,old trick.
About 2), just give it a chance, maybe it's useful and my work is not completely nonsense.
Well, I'm not a visible/vocal user base, but I do really like this TPE LSM module.
Hi Felipe,
Quoted 16 lines · Felipe Alfaro Solana
Quoted 5 lines · Lorenzo Hernández García-Hierro
Quoted 4 lines
The two biggest issues are 1) it's trivial to bypass:
$ /lib/ld.so /untrusted/path/to/program and 2) that there's no (visible/vocal) user base calling for the feature.Quoted 8 lines
About the point 1), yesterday i wrote just a simple regression test (that can be found at the same place as the patch) and of course it bypasses, this is an old commented problem, Stephen suggested the use of
the mmap and mprotect hooks, so, i will have a look at them but i'm not sure on how to (really) prevent the dirty,old trick.
About 2), just give it a chance, maybe it's useful and my work is not completely nonsense.
Quoted 2 lines
Well, I'm not a visible/vocal user base, but I do really like this TPE LSM module.
Thanks :)
I hope you will like much more the revision i'm coding right now. Tonight, my queue is a bit overloaded, i need to fix some things in the SELinux 2.4 backport, but i hope i will finish it today as it doesn't require a lot of time.
Cheers,
Signature · 2 lines
Lorenzo Hernández García-Hierro <[email protected]> [1024D/6F2B2DEC] [2048g/9AE91A22] Hardened Debian head developer & project manager