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

Reply via email to