OSEC

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: Pavel Kankovsky (peakargo.troja.mff.cuni.cz)
Date: Fri May 26 2000 - 14:15:26 CDT

On Thu, 25 May 2000, Solar Designer wrote:

> Well, LC_MESSAGES means almost everything is supported, so this can't
> be a part of a restricted mode if we make one. I agree that there're
> cases where full locale support in SUID/SGID applications is desired
> (even though these applications are broken security-wise and probably
> by other means as well) and that's why I'd like to see a nice way for
> implementing libc options that wouldn't be user-controllable and
> wouldn't require rebuilding.

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).

> I once again agree that this is the right approach in general, but in
> this case we can't disallow non-official control characters, anyway,
> even if some non-VTxxx terminal turns out to interpret them.

I thought you were speaking about characters in LC_* variables.
Is your concern someone might coax a setuid program to print controls
characters to the terminal?

> > > Perhaps there should also be an option to disable this, but it would
> > > have to be read from a file or such, which has a performance impact.
> > > Any suggestions?
> > I think the performance penalty would be negligible compared to existing
> > overhead (e.g. dynamic linking).
> This simply makes it harder to advocate such an option.

Excuse me?

On Thu, 25 May 2000, David Luyer wrote:

> And that server could eliminate the option of firing up a few dozen copies
> of ping to flood some poor guy's link.

Flood your enemy with UDP. As efficient as ICMP (unless you kernel
implements rather sophisticated congestion control) and you do not
need any privileges. (The only catch is your name might be revealed by
identd.)

P.S. I am subscibed to the list. There is no need to send me private
copies of your replies. :)

--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."