|
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: Alan Cox (alan
lxorguk.ukuu.org.uk)Date: Fri May 26 2000 - 18:11:33 CDT
- Next message: Solar Designer: "Re: Here's another glibc env. var."
- Previous message: Chris Evans: "Re: Here's another glibc env. var."
- In reply to: Chris Evans: "Re: Here's another glibc env. var."
- Next in thread: Solar Designer: "Re: Here's another glibc env. var."
- Next in thread: harada
obunsha.co.jp: "Re: Here's another glibc env. var."
- Reply: Alan Cox: "Re: Here's another glibc env. var."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> I think we need a telnetd approach. Upon exec() of privileged program, we
> nuke the entire environment apart from a list of accpetable
> variables. This code could be in glibc.
> This has the benefit that when an insecure new glibc internal
> env. var. gets added, we've protected.
Its hard to figure the env variable list out and maintain it.
Alan
- Next message: Solar Designer: "Re: Here's another glibc env. var."
- Previous message: Chris Evans: "Re: Here's another glibc env. var."
- In reply to: Chris Evans: "Re: Here's another glibc env. var."
- Next in thread: Solar Designer: "Re: Here's another glibc env. var."
- Next in thread: harada
obunsha.co.jp: "Re: Here's another glibc env. var."
- Reply: Alan Cox: "Re: Here's another glibc env. var."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]