Re: [PATCH] Enhanced Trusted Path Execution (TPE) Linux Security Module

["Lorenzo Hernández García-Hierro" <lorenzo@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 3482 bytes --]

El mié, 05-01-2005 a las 21:26 -0800, Chris Wright escribió:
> * Lorenzo Hernández García-Hierro (lorenzo@gnu.org) 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 <lorenzo@gnu.org> [1024D/6F2B2DEC]
[2048g/9AE91A22] Hardened Debian head developer & project manager

[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 189 bytes --]