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)
--
Lorenzo Hern?ndez Garc?a-Hierro <[email protected]> [1024D/6F2B2DEC]
[2048g/9AE91A22] Hardened Debian head developer & project manager
* 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.
> 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.
> 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.
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
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
El mi?, 05-01-2005 a las 21:26 -0800, Chris Wright escribi?:
> * 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.
> > 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.
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).
> > 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.
>
> 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.
> 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.
--
Lorenzo Hern?ndez Garc?a-Hierro <[email protected]> [1024D/6F2B2DEC]
[2048g/9AE91A22] Hardened Debian head developer & project manager
Hi Felipe,
El jue, 06-01-2005 a las 19:00 +0100, Felipe Alfaro Solana escribi?:
> On 6 Jan 2005, at 15:50, Lorenzo Hern?ndez Garc?a-Hierro wrote:
>
> >> 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.
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,
--
Lorenzo Hern?ndez Garc?a-Hierro <[email protected]> [1024D/6F2B2DEC]
[2048g/9AE91A22] Hardened Debian head developer & project manager
On 6 Jan 2005, at 15:50, Lorenzo Hern?ndez Garc?a-Hierro wrote:
>> 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.