On 1 Jul 2002 at 22:38, Greg Morgan wrote:
>I believe you need to correct your web site. It says that you changed
>the location of ssh_config in the packages. I believe there are two
>configuration files with one character different, a d.
>ssh.lrp contains /etc/ssh/ssh_config.
>sshd.lrp contains /etc/ssh/sshd_config.
Thanks for your comments, Greg.
Yes, there are two configuration files. Jacques' packaging has:
sshd.lrp containing
/etc/ssh/ssh_config
/etc/ssh/sshd_config
ssh.lrp does not contain any /etc/ssh/*_config files
These packages move only the /etc/ssh/ssh_config to ssh.lrp, and leave
/etc/ssh/sshd_config in sshd.lrp
My thinking was the config file should go with the program. I'm willing to
have my thinking corrected, though. (Or is it just that the web page can
have a better explanation?)
>I was reading http://www.openssh.com/txt/preauth.adv under "1. Versions
>affected:
>...
>OpenSSH 3.4 and later are not affected."
>
>
>If the package you compiled fixes this problem and numerous others,
>then is the idea here just to add additional protection by disabling
>privileges escalation? Security safeguard on another safeguard may be a
>good thing. But if privilege separation is not required in 3.4, is it
>necessary to go through this?
>
>I am just trying to sort the issues out here. Any thoughts.
Well, that's two of us trying to sort out the issues. :-)
Brief answer:
Yes, privilege separation is extra protection (against future attacks).
No, its not necessary to go through creating a new user if you disable
privilege separation in sshd_config.
Long answer: According to
http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=102495293705094&w2
Privilege separation takes ~24500 lines of code and puts it in a chroot
jail, leaving only ~2500 lines of code running as root. I believe the
thinking here is that privilege separation doesn't fix this problem
specifically; it makes it less likely for there to be privilege escalation
in the future. Privilege separation was evidently available in earlier
versions of openSSH, the difference is that it is now the default.
To answer your question "is it necessary to go through this?" for deployed
LEAF boxes, I'd probably be inclined to install the 3.4 OpenSSH, disable
privilege separation in sshd_config, and go on. That should be a simple
upgrade.
The question (for me) is what about new LEAF installations and what about
the future? One thing I really like about Bering is that Jacques is
trying to stay close to "standard."
The options that I see for ssh*.lrp are:
- compile as default, create sshd user and group
- compile with priviledge separation, but use "nobody" for chroot jail
- compile without priviledge separation enabled
At this point, a default compile of OpenSSH will use privilege separation
with the sshd user. For new LEAF installations/releases, do we want to
deviate from the (new) OpenSSH standard, or accomodate it and move on?
Either answer is fine with me, as long as there is some sort of informed
consensus.
>Redhat says they are not vulnerable.
>I did the did this in sshd_config file
>and was denied service after I applied the Redhat patch.
Funny. One of our sites changed his firewall rules to completely block
port 22 traffic. He wasn't vulnerable either. :-)
Thanks again!
Nathan
---
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
