Re: AW: [suse-security] SuSE security reputation, etc..
The issue is, that the default setup uses /etc/shadow for ssh, ftp, samba
& al. It is an extra effort to setup and maintain passwords in different
files. Apache has a different file by default.
Let this compare to Lotus Notes. When you define a user there, the system
prompts you for two different passwords. One to be used for the ID-file
that contains the private key (and is never transmitted anywhere from the
local system) and another one, that is used for HTTP basic authentication.
This is easy to understand for novice admins and little extra effort.
So, my on my whishlist to Easter Bunny:
1. Suse will add an installation/config option to make a separate pw-db
for samba and proftpd (and maybe others)
2. Suse will add a list of passwords for different packages into yast user
management.
Rainer
"OKDesign oHG Security Webmaster"
I just thought to myself:
Why is this insecure? If you login by SSH to do remote maintenance, then true, anyone who sniffs your in the clear ftp and pop passwords can login as you.
But they can only login as you the USER. They can never sniff the root password, as your "su root" password is always encrypted.
....
and then the penny dropped.
If someone ever logs into your user account. And then you login after they have done their mischief, and su, then you have just given away the crown jewels. Oh well.
Just one thought: On our system the only possibility to log in and work on the shell is SSH with RSA-authentification. So, if someone sniffs the "normal" password, okay, he can get access to the emails and for ftp-access. But NOT for any works on the system itself. Because to log in with SSH, there is a different password necessary. So, okay, this is not really secure, but at least no one can really harm the system. Or am I wrong ??? --- Stephan --------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
Rainer,
The issue is, that the default setup uses /etc/shadow for ssh, ftp, samba & al. It is an extra effort to setup and maintain passwords in different files. Apache has a different file by default.
Let this compare to Lotus Notes. When you define a user there, the system prompts you for two different passwords. One to be used for the ID-file that contains the private key (and is never transmitted anywhere from the local system) and another one, that is used for HTTP basic authentication. This is easy to understand for novice admins and little extra effort.
So, my on my whishlist to Easter Bunny: 1. Suse will add an installation/config option to make a separate pw-db for samba and proftpd (and maybe others) 2. Suse will add a list of passwords for different packages into yast user management.
Rainer
Hmmm. I agree that these two points are desirable to implement, but it is
also too complex to do. One of the side effects will be that people
complain that authentication doesn't work (because the wrong file is
active) and people comlain that SuSE doesn't keep to the standards.
We can't afford these two points in the long run. Also, modifying the
daemons/packages takes time and manpower...
It's nice project, though. Would you want to hack and maintain a set
of patches that resolve these problems in a few packages?
Thanks,
Roman.
--
- -
| Roman Drahtmüller
Hmmm. I agree that these two points are desirable to implement, but it is also too complex to do. One of the side effects will be that people complain that authentication doesn't work (because the wrong file is active) and people comlain that SuSE doesn't keep to the standards.
Not neccesarilly, make it optional.
We can't afford these two points in the long run. Also, modifying the daemons/packages takes time and manpower...
Can't it be done through PAM? I mean this is EXACTLY what PAM is meant for. #%PAM-1.0 auth required /lib/security/pam_listfile.so item=user sense=deny file= /etc/ftpusers onerr=succeed auth required /lib/security/pam_pwdb.so shadow nullok auth required /lib/security/pam_shells.so account required /lib/security/pam_pwdb.so session required /lib/security/pam_pwdb.so Maybe make a "stub" pam_pwdb called "pam_pwdb_ftp" that looks for /etc/passwd-ftp and /etc/shadow-ftp, or a pam_pwdb that takes an argument for the filename (like pam_listfile). Voila. No mods to daemons needed, power users happy, normal users blissfully unaware (unless they look into pam config files and actually make changes).
It's nice project, though. Would you want to hack and maintain a set of patches that resolve these problems in a few packages?
PAM! use the PAM!. =) -Kurt
On Mon, 07 Aug 2000, Kurt Seifried wrote:
for the filename (like pam_listfile). Voila. No mods to daemons needed, power users happy, normal users blissfully unaware (unless they look into pam config files and actually make changes).
It's nice project, though. Would you want to hack and maintain a set of patches that resolve these problems in a few packages?
PAM! use the PAM!. =)
-Kurt
None of this works without the vows and good intentions we talked about. I don't trust myself to use different passwords for different services. Or accidentally punch in the wrong one. How many of your trusted sysadmins will use the same password, or just change it by one or two characters, for ssh, ftp etc? Didn't someone earlier in the thread suggest disabling password authentication in ssh, and using only RSA public key authentication? Is there any reason why we cannot all use that (of course for commercial use in the USA we have to buy the license or wait for the patent to expire?) dproc
participants (4)
-
dproc＠dol.net -
Kurt Seifried -
rhoerbe＠netpromote.co.at -
Roman Drahtmueller