Problems with SuSE 9.1 - some issues aren't fixed for ages
Hello! There are several errors reguarding SuSE 9.1. I would better call them children <http://dict.leo.org/?p=14/p..&search=children>'s <http://dict.leo.org/?p=14/p..&search=s> disease <http://dict.leo.org/?p=14/p..&search=disease>. For users with much linux-practise it will not be a too big problem to solve them, for beginners it is an unsolveable issue and there are damn no support-pages on the SuSE homepage reguarding this issues. For this here are the issues I had and my olutions for this. @SuSE: Why are this well-known problems not fixed within a hotfix? 1) Issue: Coldplug uses by default kernelmodule hw_random which is unable to be loaded e.g. with intel-chipset motherboards. At bootup /etc/init.d/network starts magically SuSEfirewall, but SuSEfirewall should start right after networkinitialization as it can be found in init-scripts. With some networkcards this makes problems, sometimes cards refuse to work after a while or you get driver errors in /var/log/warn: Oct 6 06:25:01 tux-box kernel: NETDEV WATCHDOG: eth0: transmit timed out Oct 6 06:25:01 tux-box kernel: eth0: 21140 transmit timed out, status fc670045, SIA fffffff0 ffffffff 1c09fdc0 fffffec8, resetting... Unfortunately i don't like that. There is no security if there is no answering networkcard. O.K. I would call this bock hack-secure, because there is no network accessible. Hotfix: add hw_random to the file /etc/hotplug/blacklist PLZ fix this dear SuSE-Team!!! 2) Issue: Some services start and stop like they want. O.K. you say this is not security-related, but what happens if your desired service doesn't start because of this issue? Hotfix: Edit /etc/init.d/SERVICE and add the services to start before here: # Requires-Start: SERVICE(LIST)_TO_START_BEFORE yast/system/runleveleditor -> add and remove services and write config. Here you should know, what to do. The next reboot all will do fine. 3) Issue: Networkinitialization is confusing because of missing aliases to the apropriate network cards. If you are planning a firewall, router or gateway you maybe want to know which card is which and without beeing David Copperfield foreseeing which card will boot next time as eth0. SuSE 9.1 with kernel 2.6 uses eth-id instead of eth-aliases in /etc/modules.conf which is empty now (and the system will not care a lot what's inside an empty compatibility-file afaik maybe sooner or later in 9.2). If you use a managed switch with learning function or a license-server you need to have the right order assigned to the cards. If you use eth-id instead of ethx in SuSEfirewall all will work well, except a licenseserver, because as every user is evil the security-solution providers only allow bindings to eth0 for licenserver ehernet-id's. Hotfix: /etc/modprobe.conf.local alias eth0 MODULENAME alias eth1 MODULENAME1 Or using nameif and editing /etc/init.d/network (in the case of same cards) [...] case "$ACTION" in start) echo Setting up network interfaces: date +%s > $NETWORK_RUNFILE # Change begin if [ -e /etc/mactab ] ; then /bin/sleep 1 /sbin/nameif fi # Change end for IFACE in ${INTERFACE:- $LO [...] Edit /etc/mactab # # /etc/mactab # eth0 00:11:22:33:EA:A3 eth1 00:11:22:34:26:26 After the next reboot the cards have the right order as desired and setup in Yast. PLZ dear SuSE-Team fix this as well!!! 4) Issue: Some services can be started chroot, but all others are not offered to be started localhost only or bind to a specific Interface or IP. Hotfix: This binds Samba to 192.168.0.1 and the connected subnet: Edit /etc/samba/smb.conf and restart samba and all related services (nmb, winbind ...) [global] [...] interfaces = 192.168.0.1/255.255.255.0 socket address = 192.168.0.1 bind interfaces only = yes allow hosts = 192.168.0.0/255.255.255.0 [...] This binds mysql to locahost and makes it inaccessbile for external attacks except local exploits from errorous scripts: /etc/init.d/mysql before: $SAFE_MYSQLD \ --user=$mysql_daemon_user \ --pid-file=$pid_file \ --socket=$socket \ --datadir=$datadir &>/dev/null & after: $SAFE_MYSQLD \ --user=$mysql_daemon_user \ --pid-file=$pid_file \ --socket=$socket \ --bind-address=127.0.0.1 \ --datadir=$datadir &>/dev/null & 6) Issue: Winbind loggs the loggs full with errors because of using winbind after installing winbind with samba 3. Hotfix: Edit /etc/securety/pam_unix2.conf before: auth: call_modules=winbind nullok account: call_modules=winbind password: md5 nullok session: none after: auth: nullok account: password: md5 nullok session: none Use different authentification within smba or edit your /etc/pam.d/samba appropriate. As default Samba uses unix-auth, but you can change this and find a better solution. 7) Issue: SSH allows root to login but imo nobody wants to have this. Hotfix: Edit /etc/ssh/sshd_config and restart sshd: PermitRootLogin no 8) Issue: Limiting rights of users is not really setup secure within SuSE. Hotfix: - give www/ftp/samba-users only /bin/false - give admins /bin/bash - edit /etc/limits.conf to your needs to limit users acl's on systemlevel This should be set per default after choosing network services or serverservices packages within Yast (minimal system & no X). 9) Issue: Postfixconfiguration is a mess when using cyrus + imap + sasl-auth/smtp-auth or any other non-standard-setups. Hotfix: Drop the config and forget everything Yast and SuSEconfig is doing, instead read this: http://postfix.state-of-mind.de/patrick.koetter/smtpauth/index.html For many other issues reguarding postfix: http://www.stahl.bau.tu-bs.de/~hildeb/postfix/ 10) Errors within SuSE aren't fixed over many many distributions. There are much more children <http://dict.leo.org/?p=14/p..&search=children>'s <http://dict.leo.org/?p=14/p..&search=s> disease <http://dict.leo.org/?p=14/p..&search=disease>s in SuSE and everytime they aren't fixed, only a small remark on a support-page is written. Issue: Problem XY happens because of not enough testing SuSE's reaction: Look at the support-pages. O.K. I find a solution overytime, but isn't it more easy to implement the fixes as updates? I think you ow us this, because buying SuSE and every updated Distribution cost more, than an everage Windows distribution within their time of support. 11) Commonly used software works well, other more complex setups and their provided software works only after doing a handjob to the configs. O.K. it is easy to say this, but all bulletting boards are full of questions but less in qualified answers. This wouldn't be if there was more whise thinking within Yast and SuSEconfig. SuSEconfig always drops my handedited stuff so I disabled it by default. Linux is linux not depending on the distribution only depending on where the files are. Reguards Philippe
Philippe Vogel wrote: ...
7)
Issue:
SSH allows root to login but imo nobody wants to have this.
Hotfix:
Edit /etc/ssh/sshd_config and restart sshd:
PermitRootLogin no ...
Much of the stuff you address I don't use, so whatever. But I'll take exception to this, as your opinion is wrong. I do want root to be able to ssh into all my boxes. It what allows me to survive because I can automate copying of files for updates or shoving out new programs/scripts. It what allows me to easily jump from machine to machine as users come to me with problems; or to automate status-type commands on the fly (e.g. got a problem with this file, I wonder if the other machines have this file or a different one, let's do: for m in $machine_list; do echo $m; ssh $m cksum $file; done. It's all about automation. And all my machines are behind multiple firewalls, NAT'd, and have minimal ports open. I'm in about as secure a place as you can be (assuming you trust your users. :-) Maybe you're in a more hostile place, say as a border router; then yes, you probably don't want root to do that. But to say "nobody wants to have this" is just flat out wrong. (I'm not trying to flame you, just trying to point out that there may be situations you're not taking into account.) You can argue whether the default should be ON or OFF, but that's totally different. Kevin
Yep some people do want to login remotely as root. Some people like to be able to login as root but ONLY with a SSH key. And some people like empty root ssh passwords(!) to automate things, though it'd arguably be safer to use sudo from a non-privileged user. Different strokes for different folks (with differing levels of Paranoia!). I normally disallow root login (PermitRootLogin no), disallow empty passwords (PermitEmptyPasswords no) and disallow clear text passwords (PasswordAuthentication no). No Linux distribution is without issues AFAIK. But hey, it beats running Windows. :) -----Original Message----- From: Kevin Brannen [mailto:kevin_brannen@stercomm.com] Sent: Thursday, 7 October 2004 7:06 a.m. To: suse-security@suse.com Subject: Re: [suse-security] Problems with SuSE 9.1 - some issues aren't fixed for ages Philippe Vogel wrote: ...
7)
Issue:
SSH allows root to login but imo nobody wants to have this.
Hotfix:
Edit /etc/ssh/sshd_config and restart sshd:
PermitRootLogin no ...
Much of the stuff you address I don't use, so whatever. But I'll take exception to this, as your opinion is wrong. I do want root to be able to ssh into all my boxes. It what allows me to survive because I can automate copying of files for updates or shoving out new programs/scripts. It what allows me to easily jump from machine to machine as users come to me with problems; or to automate status-type commands on the fly (e.g. got a problem with this file, I wonder if the other machines have this file or a different one, let's do: for m in $machine_list; do echo $m; ssh $m cksum $file; done. It's all about automation. And all my machines are behind multiple firewalls, NAT'd, and have minimal ports open. I'm in about as secure a place as you can be (assuming you trust your users. :-) Maybe you're in a more hostile place, say as a border router; then yes, you probably don't want root to do that. But to say "nobody wants to have this" is just flat out wrong. (I'm not trying to flame you, just trying to point out that there may be situations you're not taking into account.) You can argue whether the default should be ON or OFF, but that's totally different. Kevin -- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
As people have said, Philippe is mistaken to suggest nobody wants to allow root ssh logins. However, I think he is quite right to say the default setting should disallow it. I'm sure everyone on this list is quite smart enough to change the setting, but we need to protect the average user who knows little about sys admin but has learnt enough to turn on sshd so that they can login to their home computer from work or vice versa. A crucial selling point for Linux is that it is safer out of the box than Windows, and we want it to stay that way. Bob Vickers
Philippe Vogel wrote: ...
7)
Issue:
SSH allows root to login but imo nobody wants to have this.
Hotfix:
Edit /etc/ssh/sshd_config and restart sshd:
PermitRootLogin no ...
/ 2004-10-07 10:50:19 +0100 \ Bob Vickers:
As people have said, Philippe is mistaken to suggest nobody wants to allow root ssh logins. However, ...
BUT. he did make some other points as well... no one interessted in those? lge
If the communication is encrypted, why is connecting as an unpriviledged user via ssh and then doing a su to root safer than connecting as root directly? Is the encryption of initial password or key verification less secure than data encryption. Or, is it to protect against dictionary attacks? What is to stop an intruder to run a dictionary attack to a regular user and then once successful run a second one with su? Yes, requiring two attacks might decrease chance of success. But, if this is the only reason then allowing only key based login is probably a lot safer than just disallowing root. Am I missing something here? Selcuk Mike Tierney wrote:
Yep some people do want to login remotely as root.
Some people like to be able to login as root but ONLY with a SSH key.
And some people like empty root ssh passwords(!) to automate things, though it'd arguably be safer to use sudo from a non-privileged user.
Different strokes for different folks (with differing levels of Paranoia!). I normally disallow root login (PermitRootLogin no), disallow empty passwords (PermitEmptyPasswords no) and disallow clear text passwords (PasswordAuthentication no).
No Linux distribution is without issues AFAIK. But hey, it beats running Windows. :)
-----Original Message----- From: Kevin Brannen [mailto:kevin_brannen@stercomm.com] Sent: Thursday, 7 October 2004 7:06 a.m. To: suse-security@suse.com Subject: Re: [suse-security] Problems with SuSE 9.1 - some issues aren't fixed for ages
Philippe Vogel wrote: ...
7)
Issue:
SSH allows root to login but imo nobody wants to have this.
Hotfix:
Edit /etc/ssh/sshd_config and restart sshd:
PermitRootLogin no
...
Much of the stuff you address I don't use, so whatever. But I'll take exception to this, as your opinion is wrong. I do want root to be able to ssh into all my boxes. It what allows me to survive because I can automate copying of files for updates or shoving out new programs/scripts. It what allows me to easily jump from machine to machine as users come to me with problems; or to automate status-type commands on the fly (e.g. got a problem with this file, I wonder if the other machines have this file or a different one, let's do: for m in $machine_list; do echo $m; ssh $m cksum $file; done.
It's all about automation. And all my machines are behind multiple firewalls, NAT'd, and have minimal ports open. I'm in about as secure a place as you can be (assuming you trust your users. :-)
Maybe you're in a more hostile place, say as a border router; then yes, you probably don't want root to do that. But to say "nobody wants to have this" is just flat out wrong. (I'm not trying to flame you, just trying to point out that there may be situations you're not taking into account.)
You can argue whether the default should be ON or OFF, but that's totally different.
Kevin
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
On Thursday 07 October 2004 15:28, Selcuk Ozturk wrote:
If the communication is encrypted, why is connecting as an unpriviledged user via ssh and then doing a su to root safer than connecting as root directly? Is the encryption of initial password or key verification less secure than data encryption. Or, is it to protect against dictionary attacks? What is to stop an intruder to run a dictionary attack to a regular user and then once successful run a second one with su? Yes, requiring two attacks might decrease chance of success. But, if this is the only reason then allowing only key based login is probably a lot safer than just disallowing root. Am I missing something here?
Other than root, how would you know the name of a user that is allowed to ssh in ? You may guess my account is named "maarten" since you saw my email, but my account could be a /bin/false one. Or it could equally possibly be any other name. Better yet, you might attack a machine you have no prior knowledge of; in that case you need to bruteforce guess not only a password but also a useraccountname. So yes, it is definitely done to prevent a dictionary attack. Additionally, su might not be available but only sudo instead, thereby adding another layer of security (and logging) purposes. Maarten -- When I answered where I wanted to go today, they just hung up -- Unknown
IMHO: The "right" way to connect is - first ssh as regular user - next, use 'sudo' (not su) to execute commands as root. The reasoning: First of all, connecting as a regular user and using sudo (or su) to switch to root will provide more accountability. In your logs, you will know which regular user logged in to become root. Probably not a big issue for a single-admin system. Overall, the idea is to execute as few commands as possible as 'root'. Next, the advantage of 'sudo' vs. 'su' is again logging, with 'sudo', commands that are executed are send to syslog, and can be logged remotely. So you will get a complete remote audit trail of all actions performed as root BTW: sometimes people use 'sudo' to provide limited root access (e.g. for a web developer that may have to restart the web server occasionally). However, doing this right is tricky. Typically, users should not be allowed to run any editors, or supply command line arguments. As a compromise: Allow root login ('PermitRootLogin yes'), but do require the use of a key (PasswordAuthentication no ... ). Next, setup keys for root that only allow the execution of specific commands. On Thu, 2004-10-07 at 09:28, Selcuk Ozturk wrote:
If the communication is encrypted, why is connecting as an unpriviledged user via ssh and then doing a su to root safer than connecting as root directly? Is the encryption of initial password or key verification less secure than data encryption. Or, is it to protect against dictionary attacks? What is to stop an intruder to run a dictionary attack to a regular user and then once successful run a second one with su? Yes, requiring two attacks might decrease chance of success. But, if this is the only reason then allowing only key based login is probably a lot safer than just disallowing root. Am I missing something here?
-- Johannes Ullrich jullrich@euclidian.com contact: http://johannes.homepc.org/contact.htm
On Thursday 07 October 2004 17:01, Johannes B. Ullrich wrote: I fully agree, but just a remark regarding this part
As a compromise: Allow root login ('PermitRootLogin yes'), but do require the use of a key (PasswordAuthentication no ... ). Next, setup keys for root that only allow the execution of specific commands.
By doing that, you disallow passwords not only for root but for everybody. If this is not what you want, you best set 'PermitRootLogin without-password' (see man sshd_config) to disable password-login for root only. Maarten -- When I answered where I wanted to go today, they just hung up -- Unknown
The right answer varies according to environment and personal taste. But the default setting has to be right for the inexperienced user who may not have a clue about key-based logins but has worked out how to set up password logins. For what it is worth I set up systems so that even if someone manages to discover the root password it is no use to them unless they either have physical access to the computer or else they also guess an administrator's regular unprivileged password. I regard that as a useful extra protection, especially on a system where there are hundreds of legitimate users but only 3 administrators allowed to use su. Bob Vickers On Thu, 7 Oct 2004, Selcuk Ozturk wrote:
If the communication is encrypted, why is connecting as an unpriviledged user via ssh and then doing a su to root safer than connecting as root directly? Is the encryption of initial password or key verification less secure than data encryption. Or, is it to protect against dictionary attacks? What is to stop an intruder to run a dictionary attack to a regular user and then once successful run a second one with su? Yes, requiring two attacks might decrease chance of success. But, if this is the only reason then allowing only key based login is probably a lot safer than just disallowing root. Am I missing something here?
Selcuk
============================================================== Bob Vickers R.Vickers@cs.rhul.ac.uk Dept of Computer Science, Royal Holloway, University of London WWW: http://www.cs.rhul.ac.uk/home/bobv Phone: +44 1784 443691
On Wednesday 06 October 2004 19:11, Philippe Vogel wrote:
Hello!
There are several errors reguarding SuSE 9.1. I would better call them children <http://dict.leo.org/?p=14/p..&search=children>'s <http://dict.leo.org/?p=14/p..&search=s> disease <http://dict.leo.org/?p=14/p..&search=disease>. For users with much linux-practise it will not be a too big problem to solve them, for beginners it is an unsolveable issue and there are damn no support-pages on the SuSE homepage reguarding this issues. For this here are the issues I had and my olutions for this. @SuSE: Why are this well-known problems not fixed within a hotfix?
1)
Oct 6 06:25:01 tux-box kernel: NETDEV WATCHDOG: eth0: transmit timed out Oct 6 06:25:01 tux-box kernel: eth0: 21140 transmit timed out, status fc670045, SIA fffffff0 ffffffff 1c09fdc0 fffffec8, resetting...
I'm no expert on this coldplug matter, but isn't this [what is seen in the logs] just a not-too-well-supported card/driver issue ?
2)
Issue:
Some services start and stop like they want. O.K. you say this is not security-related, but what happens if your desired service doesn't start because of this issue?
Hotfix:
Edit /etc/init.d/SERVICE and add the services to start before here: # Requires-Start: SERVICE(LIST)_TO_START_BEFORE
yast/system/runleveleditor -> add and remove services and write config.
Here you should know, what to do. The next reboot all will do fine.
I do not understand this... I see lines like # Required-Start: $network $syslog $remotefs in the init-scripts. What's wrong here ?
3)
Issue:
Networkinitialization is confusing because of missing aliases to the apropriate network cards. If you are planning a firewall, router or gateway you maybe want to know which card is which and without beeing David Copperfield foreseeing which card will boot next time as eth0. SuSE 9.1 with kernel 2.6 uses eth-id instead of eth-aliases in /etc/modules.conf which is empty now (and the system will not care a lot what's inside an empty compatibility-file afaik maybe sooner or later in 9.2). If you use a managed switch with learning function or a license-server you need to have the right order assigned to the cards. If you use eth-id instead of ethx in SuSEfirewall all will work well, except a licenseserver, because as every user is evil the security-solution providers only allow bindings to eth0 for licenserver ehernet-id's.
Hum, I assume this does not apply to kernels 2.4.x ? Because I've never ever had my NICs mixed / messed up after a reboot...
4)
Issue: Some services can be started chroot, but all others are not offered to be started localhost only or bind to a specific Interface or IP.
Yes. This is a (very) good point for (especially) the mysql setup. For samba I rather hesitate though, since the very point of samba is giving _remote_ machines access. I know of no people who (re)mount their own shares through samba (what would be the point, losing CPU cycles and speed?;)
6)
Issue:
Winbind loggs the loggs full with errors because of using winbind after installing winbind with samba 3.
Can't comment... This is new to me.
7)
Issue:
SSH allows root to login but imo nobody wants to have this.
That is up for debate but I for one agree with you. I'd go one further and set it to PermitRootLogin without-password
8)
Issue:
Limiting rights of users is not really setup secure within SuSE.
Hotfix:
- give www/ftp/samba-users only /bin/false - give admins /bin/bash - edit /etc/limits.conf to your needs to limit users acl's on systemlevel
This should be set per default after choosing network services or serverservices packages within Yast (minimal system & no X).
This is open for debate, too. I once played with limits a long time ago, and the only thing that lead to was "random" crashes of programs (which obviously had some sort of memory leak). And what would you suggest as figures ? On a 1GB desktop box I'd hate to have a 256MB limit on programs, and on a 128MB tiny server that same setting would be useless. Apart from that, what would be the danger of having /bin/bash on a locked account ?
9)
Issue:
Postfixconfiguration is a mess when using cyrus + imap + sasl-auth/smtp-auth or any other non-standard-setups.
Valid point, but how far are you willing to go on this ? I know a lot of setups that don't work out of the box, but then again this is not the "Enterprise Server" (where, I suppose, things are better integrated)
10)
Issue: Problem XY happens because of not enough testing
SuSE's reaction: Look at the support-pages.
Valid. Very valid. Very very valid point.
11)
Commonly used software works well, other more complex setups and their provided software works only after doing a handjob to the configs. O.K. it is easy to say this, but all bulletting boards are full of questions but less in qualified answers. This wouldn't be if there was more whise thinking within Yast and SuSEconfig. SuSEconfig always drops my handedited stuff so I disabled it by default. Linux is linux not depending on the distribution only depending on where the files are.
I beg to differ about SuSEconfig. I hardly ever get bitten by Yast overwriting my own handmade settings. Quite the opposite, I think Yast deserves a kudos for managing as good as they're doing at this point. Well, I have some of my own to add, too: With the remark that most of this is based on my experiences with 9.0, so I alas cannot really vouch for 9.1... 12) When defining a raid setup at install time, you can _add_ arrays but you cannot delete (or even change!) arrays that were previously defined. Similarly, I doubt that the integration of mdadm (and /etc/mdadm.conf!!) is yet near complete. 13) The HWdb is old / unmaintained / awkward. Try and find out which gigabit ethernet cards are supprted and which are not. You will not succeed... 14) The hotplug mechanism for inserting USBdrives is either broken or just too opaque for me. One cannot make desktop icons / shortcuts for a card since after boot the cards get IDs based on the order you insert them. Furthermore, cards with more than 1 partition are not fully recognized. 15) Grub and Lilo still (sometimes) pose near insurmountable problems when dealing with raid devices. The rescue media are not well suited to fix these issues. (I'll admit this also stems from my insufficient knowledge of installing grub manually though) 16) The IDE DMA settings do set DMA mode but omit the 3 other speed-enhancing settings (hdparm -m16 -u1 -c1). This is open for debate however (see man hdparm) so it might be a conscious decision. Maarten -- When I answered where I wanted to go today, they just hung up -- Unknown
participants (8)
-
Bob Vickers -
Johannes B. Ullrich -
Kevin Brannen -
Lars Ellenberg -
maarten -
Mike Tierney -
Philippe Vogel -
Selcuk Ozturk