|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Subject: Re: Here's another glibc env. var.
From: Crispin Cowan (crispin
wirex.com)Date: Tue May 30 2000 - 10:55:20 CDT
- Next message: Sean Hunter: "Re: [RFC] environment sanitisation wrapper"
- Previous message: Kurt Seifried: "Re: [RFC] environment sanitisation wrapper"
- In reply to: Pavel Kankovsky: "Re: Here's another glibc env. var."
- Next in thread: harada
obunsha.co.jp: "Re: Here's another glibc env. var."
- Reply: Crispin Cowan: "Re: Here's another glibc env. var."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Pavel Kankovsky wrote:
> Let me explain an idea I had recently: whenever execve() is called on a
> s[ug]id binary, the kernel would load and run a specified "wrapper"
> program (whose path would be configurable) that would sanitize the
> environment and (when it thinks the environment is safe) it would
> re-execute the original program (s[ug]id script-like race condition must
> be avoided here). Yes, Alan, I see you getting ready to object <g> but
> unlike fd-0,1,2 patch, this mechanism would be absolutely policy-neutral,
> the policy would be enforced by a program living in the userland
> (and one could even configure different policies for different programs).
There are two projects very close to what you propose:
* Terry Mitchem, Raymond Lu, and Richard O'Brien of Secure Computing
Corp.
did a project called "Kernel Hypervisors", which you can read about
here
[1]
* Tim Fraser, Lee Badger, and Mark Feldman described a very similar
project
called "Generic Software Wrappers" which you can see here [2]
Our own SubDomain project ( http://immunix.org/products.html#subdomain )
is
somewhat more distant. Instead of providing a facility to allow you to
insert
a generic wrapper, we abstracted away that complexity and just provide a
policy
machine for what you mostly care about: file system acccess. SubDomain
lets
you specify what files may be read, written, or executed on a
per-program
basis, helping to secure the system against problems in SUID programs.
[1]
inproceedings{
hypervisor97,
author = "Terrance Mitchem and Raymond Lu and Richard O'Brien",
title = "{Using Kernel Hypervisors to Secure Applications}",
booktitle = "Proceedings of the Annual Computer Security Application
Conference",
month = "December",
year = 1997
}
[2]
inproceedings{
badger99,
author = "Tim Fraser and Lee Badger and Mark Feldman",
title = "{Hardening COTS Software with Generic Software Wrappers}",
booktitle = "Proceedings of the IEEE Symposium on Security and
Privacy",
address = "Oakland, CA",
month = "May",
year = 1999
}
Crispin
-----
Crispin Cowan, CTO, WireX Communications, Inc. http://wirex.com
Free Hardened Linux Distribution: http://immunix.org
JOBS! http://immunix.org/jobs.html
- Next message: Sean Hunter: "Re: [RFC] environment sanitisation wrapper"
- Previous message: Kurt Seifried: "Re: [RFC] environment sanitisation wrapper"
- In reply to: Pavel Kankovsky: "Re: Here's another glibc env. var."
- Next in thread: harada
obunsha.co.jp: "Re: Here's another glibc env. var."
- Reply: Crispin Cowan: "Re: Here's another glibc env. var."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]