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

Re: itp: static bins / resolving static debian issues



* Algis Rudys said:
> Hi folks:
> I'm rather new to this list, so kindly forgive me if it shows. 
> 
> First a brief comment -- I hadn't heard of sash until it was mentioned
> here. I can't imagine that many Debian users reading the description of
> every optional and extra package available looking for ones they might
> have a need for.... not to mention the description for sash doesn't
> explicitly point out its usefulness as a recovery shell. 
It's implied:

'The purpose of this program is to make replacing of shared libraries easy
and safe.  It does this by firstly being linked statically, and secondly by
including many of the standard utilities within itself.'
 
> > Nope. I've never been opposed to a local admin making /bin/sash his
> > default root shell--that's the way I do things here. But that's another
> > local configuration issue and shouldn't be a general default.
> 
> I tend to disagree, and here's why: 
> What root's shell is, is the local configuration issue. Debian should
> provide a sensible default. More on that later....
> 
> Likewise, what users have superuser privileges, is a local configuration
> issue. In my (admittedly limited) experience, and from what I have read
> from various security mailing lists and newsgroups, having multiple UID
> 0 users can be a security hazard; it requires extra administrative
> effort to maintain the extra account (ie make sure to change the
> password along with the root password, keep track of access to this
> account as well, etc). 
Not at all. It's an easy task to make updating the two accounts' passwords a
seamless process. After all, you are the administrator and you have to
realize what are the possible consequences. Writing a script that COPIES
your freshly changed root password to the alternative account is not a very
complicated thing to do. So the administrative effort is limited to wrapping
up a standard passwd call in some nice script and using it while changing
password on the root account.
 
> Basically, it introduces an additional point of failure in Debian's
> security structure. This should not be taken lightly. In any case, it
> strikes me that a second superuser account should be the non-default
> "local configuration issue" that admins have to settle. 
Why is it a security hazard??

[snip]
> It strikes me that given the reliability advantage for the people
> (however few) who may find sash useful, against the inconvenience, sash
> should be the default root shell where it is installed. 
No. It's been discussed already and many of us, originally voting in favor
of what you just written, have changed their minds. sash isn't a
POSIX-compliant shell and doesn't have scripting capability - it wasn't
designed to be a standard shell, but an emergency one.

> In addition, one common concept that comes up periodically in security,
> and applies here, is failsafe defaults. That is, if a person does
> nothing to modify the behavior, it does what is safest, most reliable,
> etc. It seems that, if sash is installed, it should be made as the
> default root shell. 
Or provisions should be made to easily switch to sash in case of emergency.
And that's a much better way, IMO.

[snip]
> elsewhere in the thread. Note that some users lacking in clue may find
> it useful to have, and considering the costs and benefits, it strikes me
> that we should give it to them. There is nothing to be gained by making
> life difficult for such people. 
This issue has been a real PITA in that thread, but I think that the loss
(~300KB) of space on the disk is nothing compared to actually having sash
ALWAYS handy.

> Here is what I suggest: 
> currently sash is priority optional. When installed, it asks you if you
> want to change root's login shell to sash. Default is "no". 
> 
> Change this to:
> set the priority of sash to standard or important. On install, ask if
> you want to make this the default root shell. Default to "yes". Say
No. It should be installed as a part of the standard installation process
and used as the alternative sashroot account shell.

> Of course I've been in such a situation, but IMHO the philosophy should
> be, if it helps even one user to recover cleanly where that user didn't
> have the presence of mind (or the spare time) to create a spare root,
> then it's worth including the respective tools. 
Exactly!! Doesn't matter HOW many times it will be needed - matters that IT
IS THERE in case it is needed.
 
marek

Attachment: pgpn37rfTyxqz.pgp
Description: PGP signature


Reply to: