linux-kernel - Re: [PATCH] Undo some of the pseudo-security madness

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 22 Jan 2007 04:53:29 +0300
From:	Samium Gromoff <_deepfire@...lingofgreen.ru>
To:	Kyle Moffett <mrmacman_g4@....com>
Cc:	David Wagner <daw-usenet@...erner.cs.berkeley.edu>,
	LKML Kernel <linux-kernel@...r.kernel.org>,
	Samium Gromoff <_deepfire@...lingofgreen.ru>
Subject: Re: [PATCH] Undo some of the pseudo-security madness

At Sun, 21 Jan 2007 19:36:27 -0500,
Kyle Moffett wrote:
> 
> On Jan 21, 2007, at 18:34:56, David Wagner wrote:
> > [1] In comparison, suidperl was designed to be installed setuid- 
> > root, and it takes special precautions to be safe in this usage.   
> > (And even it has had some security vulnerabilities, despite its  
> > best efforts, which illustrates how tricky this business can be.)   
> > Setting the setuid-root bit on a large complex interpreter that  
> > wasn't designed to be setuid-root seems like a pretty dubious  
> > proposition to me.
> 
> Well, there's also the fact that Linux does *NOT* need suidperl, as  
> it has proper secure support for suid pound-bang scripts anyways.   
> The only reason for suidperl in the first place was broken operating  
> systems which had a race condition between the operating system  
> checking the suid bits and reading the '#! /usr/bin/perl' line in the  
> file, and the interpreter getting executed and opening a different  
> file (think symlink redirection attacks).  I believe Linux jumps  
> through some special hoops to ensure that can't happen.

Uh, this does not work, unfortunately in the Lisp case.

Lisp environments can produce standalone executables, which are

1. supposed to be runnable like a usual binary, without any additions
2. will suffer from the very same problem, as it merely is a
runtime bundled with the core file

(and the core file is unrelocatable)

> Kyle Moffett

regards, Samium Gromoff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/