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

Re: More bugs in 0.91 ...



>>>>> "Ian" == Ian Jackson <iwj10@cus.cam.ac.uk> writes:
    Ian> * `su' should not be aliased in /etc/profile.  Firstly, the
    Ian> profile is the wrong place (aliases are not exported) and
    Ian> secondly `su' should be just vanilla `su' by default.

I agree with this, su should be left alone and unaliases.  I would
like to point out that by default the ~/.bashrc sources /etc/profile,
so that is why the aliases are "exported" to the users. 

    Ian> * `rm', `cp' and `mv' should not be aliased in root's default
    Ian> profile.  Same two reasons as above.  "To avoid accidents" is
    Ian> a poor reason to make these aliases - they will merely
    Ian> confuse people, and cause accidents when people don't have
    Ian> them and annoyance when they do.  If you must, make a general
    Ian> alias `del' or some such for `rm -i'.

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

    Ian> * Various files in .../sbin aren't readable/executable by
    Ian> normal users.  This is silly.  We have in /sbin: brc, getty,
    Ian> ifconfig, ifsetup, lilo, route, uugetty in /usr/sbin: crond,
    Ian> iflink, lpc, lptest, miscd, pac

>From the FSSTD:
-------------------------------------------------------------------------------
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.

Jim


Reply to: