Hi Kurt, Hi Folks, Kurt Seifried wrote: Friday, October 26, 2001 11:05 PM Subject: Re: [suse-security] I forgot my root password
Using init=/bin/sh is a LOT more simple if you don't have a cdrom for example (most of my servers don't have cdrom drives). the init=/bin/sh will work, no matter what unless someone has locked down lilo with restricted and password.
Ok, you won. But I still think that this "cryptic" way is more complicated than my suggestion. Using init=/bin/sh is more ultimative than my solution, but what do you do when the sh (I think it's only optional) is not installed (if want to avoid opening the box)? For that case, I guess you should have a rescue-boot-disk with all the tools you need, if you forgot the password or the system crashed. So you're independant from the installed system (and you should be). Greetings Guido
No. /bin/sh is not really optional on any install (that I've ever seen). If it is that vendor would be seriously breaking with tradition, there is a very good reason for a small statically linked shell. In most cases now it is linked to bash (i.e. literally a symlink) which is unfortunate because bash is often nolonger compiled statically, meaning if you lose one critical library you are really up the creek. Still it's more reliable then hoping for a cdrom drive for most headless servers =). Another alternative is to boot from floppy and use rescue via network. Kurt Seifried, kurt@seifried.org A15B BEE5 B391 B9AD B0EF AEB0 AD63 0B4E AD56 E574 http://www.seifried.org/security/
On Sat, 27 Oct 2001, Steffen Dettmer wrote:
login as root with no password, reset root password.
This would offer a small window for attacker/scanners which could install a backdoor on networked systems. Don't do that except at home :)
I agree you must be careful, but with the right option to lilo you can boot into runlevel 1. Am I right in thinking that all network connections, and all ttys and gettys except the local console, will be down? I think this means you are ok. On Sat, 27 Oct 2001, Kurt Seifried wrote:
for a cdrom drive for most headless servers =). Another alternative is to boot from floppy and use rescue via network.
There are still rescue systems that run entirely from floppy -- aren't there any suitable floppy images on the latest distributions? I have a floppy of tomsrtbt in case the SuSE boot floopy isn't enough. dproc
No. /bin/sh is not really optional on any install (that I've ever seen). If it is that vendor would be seriously breaking with tradition, there is a very good reason for a small statically linked shell. In most cases now it is linked to bash (i.e. literally a symlink) which is unfortunate because bash is often nolonger compiled statically, meaning if you lose one critical library you are really up the creek. Still it's more reliable then hoping for a cdrom drive for most headless servers =). Another alternative is to boot from floppy and use rescue via network.
We know of the old tradition of statically linking /bin/sh, we would like to have it, but it doesn't work that way. With modern glibc systems, static linking is not supported any more, mostly because of the language/localization support. If it was all that easy, we'd have it there.
Kurt Seifried, kurt@seifried.org
Thanks,
Roman.
--
- -
| Roman Drahtmüller
Hi, On Monday 29 October 2001 11:10, you wrote:
No. /bin/sh is not really optional on any install (that I've ever seen). If it is that vendor would be seriously breaking with tradition, there is a very good reason for a small statically linked shell. In most cases now it is linked to bash (i.e. literally a symlink) which is unfortunate because bash is often nolonger compiled statically, meaning if you lose one critical library you are really up the creek. Still it's more reliable then hoping for a cdrom drive for most headless servers =). Another alternative is to boot from floppy and use rescue via network.
We know of the old tradition of statically linking /bin/sh, we would like to have it, but it doesn't work that way. With modern glibc systems, static linking is not supported any more, mostly because of the language/localization support.
If it was all that easy, we'd have it there.
You have it (almost). How about /bin/sash? I think it's in the default SuSE installation. Usually sufficient for recovery purposes.
Kurt Seifried, kurt@seifried.org
Thanks, Roman.
Regards, Martin -- Martin Leweling Institut fuer Planetologie, WWU Muenster Wilhelm-Klemm-Str. 10, 48149 Muenster, Germany
* Martin Leweling wrote on Mon, Oct 29, 2001 at 13:47 +0100:
On Monday 29 October 2001 11:10, you wrote:
If it was all that easy, we'd have it there.
You have it (almost). How about /bin/sash? I think it's in the default SuSE installation. Usually sufficient for recovery purposes.
AFAIK it is not installed by default. I have a sash on the machines, and I really like it. It's powerful for such emergency-cases. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
I think it is more important to have a small statically linked shell available for emergencies -- AND shells for daily use that have multi-language support -- than to remove something essential because it doesn't have multi-language support. This is even a security issue, in some cases. Dynamically linked shells are vulnerable to shared-object spoofs. Bear
* Ray Dillinger wrote on Thu, Nov 01, 2001 at 07:40 -0800:
I think it is more important to have a small statically linked shell available for emergencies
sash is excactly that. Additionally, it has a lot of built-in features, even mount can be used (without /bin/mount). So you can remount even a root partition under some circumstances.
This is even a security issue, in some cases. Dynamically linked shells are vulnerable to shared-object spoofs.
Well, you're right, but I feel this thread is more about data safeness that security in the sense of this list :) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
My boxed Suse 7.3pro just walked in the door, and I am contemplating fireing up yast and doing the Update Existing installation routine to replace the 7.1 install currently on the machine. Since I have not done this with Suse before, I'm a little worried. Yes I'll take a backup, but what I really want to know from Suse Sourdoughs (Alaskan for Veterans), is wether this is a good idea or does it munge things more often than not? (Another of the never ending data SECURITY questions). -- __________________________________________ J.Andersen.
My boxed Suse 7.3pro just walked in the door, and I am contemplating fireing up yast and doing the Update Existing installation routine to replace the 7.1 install currently on the machine.
Since I have not done this with Suse before, I'm a little worried. Yes I'll take a backup, but what I really want to know from Suse Sourdoughs (Alaskan for Veterans), is wether this is a good idea or does it munge things more often than not?
(Another of the never ending data SECURITY questions).
Upgrade from an older distribution should work, especially if it is 7.1
and newer (think of the init script changes from 7.0 to 7.1: /sbin/init.d
-> /etc/init.d). Watch the output of the rpm commands during the
installation to see if something goes wrong. Configuration files should
not get touched.
If the old system is a 7.0 or older, manual help is needed in the case
where you have added init scripts by yourself. This could turn out to be a
bit messy, to be honest. But it works.
Roman.
--
- -
| Roman Drahtmüller
John Andersen wrote:
My boxed Suse 7.3pro just walked in the door, and I am contemplating fireing up yast and doing the Update Existing installation routine to replace the 7.1 install currently on the machine.
Since I have not done this with Suse before, I'm a little worried. Yes I'll take a backup, but what I really want to know from Suse Sourdoughs (Alaskan for Veterans), is wether this is a good idea or does it munge things more often than not?
(Another of the never ending data SECURITY questions).
I don't have experience with 7.3, but the 6.4 to 7.1 (I've done several) replaces most package configuration files with default ones. Happily, it saves the old configs and tacks .rpmsave to the end. Unhappily, you now have to test your system to see what broke (Sendmail is fine and complex example), and re-integrate you changes into the new default config files. Lost In Tokyo, Keith
participants (9)
-
dproc＠dol.net -
Guido Schiffer -
John Andersen -
Keith Hopkins -
Kurt Seifried -
Martin Leweling -
Ray Dillinger -
Roman Drahtmueller -
Steffen Dettmer