[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Rationale

On Mon, 01 Dec 2003 19:49:16 +0100, John Smith wrote:

> On Mon, 2003-12-01 at 08:13, Karsten M. Self wrote: 
>> on Sun, Nov 30, 2003 at 11:01:35PM +0100, John Smith (netman1@home.nl) wrote:
>> > Hi All,
>> > 
>> > 	checked google, asked this before on irc, didn't get a 
>> > usable answer (can't find any use of /etc/login.defs).
>> > 
>> > 	What is the rationale behind the PATH environment variable?
>> > Running woody I get 
>> > 
>> > /usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
>> > 
>> > as a normal user. As root I get
>> > 
>> > /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:
>> > /usr/bin/X11
>> > 
>> > Thinking security I would expect them the other way around. 
>> Then change it.
>> If you're not allowing world write to /usr/local/(s)bin, you should be
>> OK.  The usual justification is that your locally defined commands
>> superscede system commands.
>> Peace.
> Gentlemen,
> 	thanks for your remarks, they answer most of my questions,
> as did a thorough grep session on debian-policy, (thanks Paul). What
> I'm bothered with is that convenience takes precedence over security
> in this case. The example of an [evil/compromised] application
> manager with write access to one of the /local directories, who
> inserts a trojan named passwd is probably obvious to all. <Asbestos>
> Two other os-es that I'm thoroughly familiar with, Netware and 
> Windows, insert for this exact reason the system paths before the
> local paths. </Asbestos>
> 	Karstens remark that I'm allowed to change this, brings the
> obvious question: does this break things? So if I change the default
> paths to /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
> and /bin:/usr/bin:/usr/local/bin, will this prevent things from
> working?
> Last extra question: does /etc/login.defs work or not? 
> Sincerly,
> Jan.

It shouldn't break anything unless you have created executables with the
same names as the system with the intent that they should be substituted
for the system executable (e.g. creating /usr/local/bin/rm which runs rm

The locals weren't in my default root path or user path, anyway.  Although
I have added them to the end of both.

The key in any case is to protect your /usr/local... from anyone except
root writing to it, and also not to put current directory in root's path. 
/usr/local... doesn't exist so non-admins can put commands in there;  they
should be putting them in somewhere in their /home or in their apps


"The average lifespan of a Web page today is 100 days. This is no way to
run a culture."

Internet Archive Board Chairman

Reply to: