Aliases for root & /sbin permissions
Ian Jackson <iwj10@cus.cam.ac.uk> writes:
>> * `rm', `cp' and `mv' should not be aliased in root's default
>> profile. Same two reasons as above. "To avoid accidents" is
>> a poor reason to make these aliases - they will merely
>> confuse people, and cause accidents when people don't have
>> them and annoyance when they do. If you must, make a general
>> alias `del' or some such for `rm -i'.
James A. Robinson <jimr@simons-rock.edu> writes:
> I disagree with this, in my opinion root should not have plain rm
> period. If somebody is expert enough to not have 'rm -i' they should
> be expert enough to know how to unalias it. But both our opinions are
> just that, and probably don't have much more then that to back them
> up then what we stated (preferences).
No. Nothing, absolutely nothing should be aliased by default in the
root account. There are "non-opinion" reasons for this to be the
default behavior.
1. *Not* aliasing rm is standard on *all* UNIX systems
2. No UNIX System Administration Guide on this Earth advocates doing
such a thing.
3. Consistent behavior across all UNIX systems. The single day that
you do "rm *" (as the same dumb asses you think you are
protecting WILL do) is the same day you find out Sun or HP or DEC
or whatever doesn't have your nice little friendly alias.
This isn't for experts, but for the people who don't know any better.
Proper system administration and learning how to manage a UNIX system
is not done by aliasing "rm" or any crap like that. Sorry, but this
aliasing is a silly idea.
>> * Various files in .../sbin aren't readable/executable by
>> normal users. This is silly. We have in /sbin: brc, getty,
>> ifconfig, ifsetup, lilo, route, uugetty in /usr/sbin: crond,
>> iflink, lpc, lptest, miscd, pac
>From the FSSTND 1.0:
------------------------------------------------------------------------
Users should have execute permission for everything in /sbin that can
be executed by non-root users. The division between /bin and /sbin
was not created for security reasons or to prevent users from seeing
the OS, but to provide a good division between binaries that everyone
uses and the ones that are primarily used for administration tasks.
There is no inherit security advantage in making /sbin off-limits for
users.
------------------------------------------------------------------------
> This would support what you say, and I guess the real discussion
> should be on what programs need to be secured.
Only setgid and setuid programs need to be secured and I believe that
all of the ones in Debian are safe, but I could be wrong, I suppose.
Dan
--
Daniel Quinlan <quinlan@spectrum.cs.bucknell.edu>
Reply to: