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
-i).
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
directories.
--
....................paul
"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: