Re: [Leaf-devel] OpenSSH security

[Greg Morgan]

Nathan Angelacos wrote:
> 
> On 1 Jul 2002 at 22:38, Greg Morgan wrote:
> 

> 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.

Thanks. Your paragraph provides some additional information I had not
received.  It appears to be a simple choice based on the above
information. chroot is better.

Greg Morgan


---
This sf.net email is sponsored by:ThinkGeek
No, I will not fix your computer.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] sh-httpd mods

[Greg Morgan]

"Charles Steinkuehler" <[EMAIL PROTECTED]> wrote:

> This is a call for those who have done mods to the sh-httpd code to
> merge their changes into CVS, either directly (preferred...only possible
> if you're a registered LEAF developer), or by sending me a patch so I
> can do it (I'm too busy, or this would be the preferred method).
> 
I posted a possible fix on the DCD wish list titled "Alter weblet
disk-checking script to ignore CD-ROM (always 100% full)" issue.  The
modified code is for checkdisk.

Here's the original post.
http://www.mail-archive.com/leaf-user@lists.sourceforge.net/msg06064.html

I am not a registered developer so here is the diff.

diff -u checkdisk checkdisk.new
--- checkdisk   Tue Oct 30 05:38:42 2001
+++ checkdisk.new   Tue Jul  2 22:36:52 2002
@@ -27,6 +27,16 @@
 bkg='BGCOLOR="#33ff33"'

 for line in `df | grep /dev/` ; do
+   # Look at the greped line returned from df.
+   # Error reporting is only concerned about shortage of space
+   # on both floppy drives and ram drives.
+   # All other mounted media is presumed to be some sort of
+   # readonly boot media.  The default case statement, *)
+   # will ignore readonly media especially cdroms.
+   case $line in
+ # Search for /dev/fd* and /dev/ram* lines to calculate
+ # drive capacity ratios.
+   *fd*|*ram*)
IFS=$OIFS
set -- $line

@@ -52,6 +62,11 @@
[ "$free" -le "${WRN_K}" ] && setwarn
[ "$pcnt" -le "${ERR_PCNT}" ] && seterror
[ "$free" -le "${ERR_K}" ] && seterror
+   ;;
+   *)
+   continue
+   ;;
+   esac
 done

 case $func in


---
This sf.net email is sponsored by:ThinkGeek
No, I will not fix your computer.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] OpenSSH security

[Michael D. Schleif]

Nathan Angelacos wrote:
> 
> >I'm curious about /etc/group modification?
> >
> >I've upgraded two (2) potato's and two (2) woody's.  Yes, there is a
> >new user in passwd/shadow; but, I do not have any new group for
> >sshd.
> >
> >Yes, I have seen the instructions for installing manually; but, I
> >cannot find a reason for the special group.
> >
> >What do you think?
> 
> Good question.  I wondered the same thing, figured "'cause Theo said
> so.." and dismissed it.  But after you asked, I checked the source...
> :-)
> 
> sshd.c in privsep_preauth_child does a setgid() from the sshd's
> primary group (in passwd) when setting up the chroot jail.  The
> manual instructions make sure that the uid:gid is sshd:sshd.
> So I guess "'cause Theo said so" works. :-)
> 
> I'm curious though, on your debian systems, what is the gid for the
> sshd user?  The sshd.c source seems to indicate that sshd will fail
> if the group doesn't exist.

Precisely my point!  sshd is working without incident on all of these
boxen.  I thought the same as you, that this should fail of give me some
kind of error log; but, I haven't found anything wrong and I've been
using it for nearly a week now ;<

How can I check which gid it's using, since once it's successfully
logged in it resorts to root?

What do you think?

-- 

Best Regards,

mds
mds resource
888.250.3987

Dare to fix things before they break . . .

Our capacity for understanding is inversely proportional to how much we
think we know.  The more I know, the more I know I don't know . . .


---
This sf.net email is sponsored by:ThinkGeek
No, I will not fix your computer.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] sh-httpd weblet web-config

[guitarlynn]

On Tuesday 02 July 2002 10:29, Charles Steinkuehler wrote:

> > 2) authentication may be an issue, but maybe this would bloat
> > weblet, especially if we still want to support floppies
>
> I'd prefer to avoid the authentication entirely with sh-httpd, but
> basic authentication may be required.  Note that even if implemented,
> I wouldn't really consider this amazingly secure...it would simply be
> a way to provide some sort of password so Junior couldn't edit the
> firewall rules on a whim, enabling the latest [mal|share]ware program
> to work.
>
> I think any form of secure authentication, as well as any encryption
> or tunneling should be handled by a seperate program (ie ssh, ssl,
> zeebee, or similar).

After checking quite a few options available, I believe IDE releases
should use ssh tunneling since it is likely already being used and 
floppy images should use zeebelee for space limitations. The Weblet
would be limited to localhost and all configuration would be
authenticated via the particular tunnel program used. I suppose zeebedee
could be used for everything, but I'm not sure how two tunneling
programs would react to each other if used at the same time. This would
also limit the security risk due to any code we produce.
-- 

~Lynn Avants
aka Guitarlynn

guitarlynn at users.sourceforge.net
http://leaf.sourceforge.net

If linux isn't the answer, you've probably got the wrong question!


---
This sf.net email is sponsored by:ThinkGeek
No, I will not fix your computer.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] sh-httpd weblet web-config

[guitarlynn]

On Tuesday 02 July 2002 08:33, Charles Steinkuehler wrote:

> First, a point of order.  In my view of the world, there are two
> major issues currently being discussed:

> I think it would probably help prevent confusion if mods to the web
> server itself refer to sh-httpd, while issues related to making
> html/cgi code to monitor or configure the system use the weblet
> moniker.

Agreed, I attempted to clarify this earilier. I considered anything with
configuration a "seperate entity", but if Weblet is modularized the 
argument is moot.


> With that out of the way, I completely agree with the idea of forming
> a "group" to work on the weblet portion of the configuration problem.
> This can probably be done with very little effort completely within
> the bounds of the existing LEAF SF project.  With a CVS directory
> somewhere in the existing LEAF tree, folks can share code and
> updates, and even developers w/o LEAF SF developer status can
> check-out code and posts diffs to the leaf-devel mailing list (much
> like the way the busybox list works...I've sent in several bug-fixes
> to busybox that got incorperated into the main code-base, but am not
> a registered busybox developer).  I think the leaf-devel mailing list
> will work fine as a communications mechanism for now, and we can
> always make a new leaf mailing list if the traffic gets too high for
> the leaf-devel list (unlikely, at least for now).

This is fine, I was making sure this was an "approved" method in
accordance with the site admins.


> I can commit to help with the sh-httpd mods, and I think I can
> improve the performance of cgi scripts dramatically.  I can probably
> help with a bit of the html/cgi scripting (ie general architecture
> and maybe solving any thorny scripting issues that crop up), but I
> don't have time to commit to a huge chunk of the project.

I don't have a huge amount of time myself, but I can work on the
core integration with the present Release(s) configuration to a
script-based one. In honesty, I really haven't gone through much
of the present CGI/Weblet scripts yet. If I can catch up with Richard's
changes, I'll be happy to help in any manner there as well.
It appears that I was working in a reverse order to everyone else... ;-)


> It looks like Richard's generally headed in the right direction with
> his mods to the existing html/cgi code, especially with the
> abstraction of the content.  Has anyone else made much progress along
> these lines, or should work start on using Richard's framework to
> start building a web-config architecture?

I think Richard is further along than anyone else with Weblet, I could
contribute some form templates and some variable/conf file proposals
as well.
-- 

~Lynn Avants
aka Guitarlynn

guitarlynn at users.sourceforge.net
http://leaf.sourceforge.net

If linux isn't the answer, you've probably got the wrong question!


---
This sf.net email is sponsored by:ThinkGeek
No, I will not fix your computer.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] OpenSSH security

[Nathan Angelacos]

>I'm curious about /etc/group modification?
>
>I've upgraded two (2) potato's and two (2) woody's.  Yes, there is a 
>new user in passwd/shadow; but, I do not have any new group for 
>sshd.
>
>Yes, I have seen the instructions for installing manually; but, I 
>cannot find a reason for the special group.
>
>What do you think?

Good question.  I wondered the same thing, figured "'cause Theo said 
so.." and dismissed it.  But after you asked, I checked the source... 
:-)

sshd.c in privsep_preauth_child does a setgid() from the sshd's 
primary group (in passwd) when setting up the chroot jail.  The 
manual instructions make sure that the uid:gid is sshd:sshd.  
So I guess "'cause Theo said so" works. :-)

I'm curious though, on your debian systems, what is the gid for the 
sshd user?  The sshd.c source seems to indicate that sshd will fail 
if the group doesn't exist.






---
This sf.net email is sponsored by:ThinkGeek
No, I will not fix your computer.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[Leaf-devel] [ leaf-Patches-576599 ] ip-graph

[noreply]

Patches item #576599, was opened at 2002-07-02 14:00
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=313751&aid=576599&group_id=13751

Category: packages
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: ip-graph

Initial Comment:
I created this package as a result of many DENY/REJECT
lines in my syslog file. This package reads your syslog 
file and extracts the ip address and port number of the 
offender and creates a file containing the extracted info.
Then, a script reads the newly created file and 
generates a DENY without logging entry in the 
ipfilter.conf file. Thus, I get fewer entries in my logs.
The scripts also do the following;
1. The file is sorted so there is only one entry of a given 
ip address.

2. When run on a cron, the created file is recycled on 
the first of the month to rid the file of any stagnate 
addresses.

3. The original weblet has been modified to include a 
dynamic graphing of ports that have had rules applied.

4. The package is self maintaining.

MAWK and SORT are required. 
I have this running on Eiger and have done some 
running on Dachstein.

You can see it online at www.vette66.com

Thanks,
chuck
([EMAIL PROTECTED])

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=313751&aid=576599&group_id=13751


---
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] OpenSSH security

[Michael D. Schleif]

Jacques Nilo wrote:
> 
[ snip ]

> > 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?
> >
> I have a clear position on this: we should stick to the new default openssh
> config which implies privilege separation an therefore the creation of a sshd
> user and group (Debian does this, Mandrake as well)
> I will update Bering accordingly for the final release and update my openssh
> package suite accordingly.

I'm curious about /etc/group modification?

I've upgraded two (2) potato's and two (2) woody's.  Yes, there is a new
user in passwd/shadow; but, I do not have any new group for sshd.

Yes, I have seen the instructions for installing manually; but, I cannot
find a reason for the special group.

What do you think?

-- 

Best Regards,

mds
mds resource
888.250.3987

Dare to fix things before they break . . .

Our capacity for understanding is inversely proportional to how much we
think we know.  The more I know, the more I know I don't know . . .


---
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

Re: [Leaf-devel] sh-httpd weblet web-config

[Charles Steinkuehler]

> One thing I would like to see is for people to realy look at HOW
things are
> being done in the current weblet code to offer better ways to
accomplish these tasks.
> For instance I'm wondering if there is a better way to incert HTML
snipits than  the
> cat <<- /HTML
> /HTML
> Construct.  (Not that I know one, just interested)

Agreed, although unless someone wants to *REALLY* start crawling through
the code, this will require a fair amount of emperical data gathering
(ie real-world testing) to determine optimum methods.  Note that in some
tests I've done, bash and ash differ considerably on how fast they
handle various text manipulation funtions (bash was actually a fair
amount slower).

> Also the curent textTOhtml does not deal with indentation of text
files well, or at all.  This is a problem.

Yes, the current text2html pretty much sucks, but it's better than just
dumping the file outright :-)  Improvements are welcomed...

BTW If you want indenting saved, you should wrap the text2html output
with pre-formatted tags (ie ...), or maybe ...

Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)



---
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

Re: [Leaf-devel] OpenSSH security

[Jacques Nilo]

Le Mardi 2 Juillet 2002 18:20, Nathan Angelacos a écrit :
> 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?)
>
There was an explanation at the time I created the packages but honnestly I 
just cannot remember it :-)

> 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.
>

> 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?
>
I have a clear position on this: we should stick to the new default openssh 
config which implies privilege separation an therefore the creation of a sshd 
user and group (Debian does this, Mandrake as well)
I will update Bering accordingly for the final release and update my openssh 
package suite accordingly.

Jacques


---
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

RE: [Leaf-devel] RE: [leaf-user] Weblet Dev Demo Update

[Richard Amerman]

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
Sent: Tue 7/2/2002 6:50 AM 


>I know what he meant about the hosts.allow. I noticed it yesterday!
>Your syslog file has lots of these messages in it:
> Jul 2 07:01:09 BeringFWWeblet sh-httpd[11991]: warning: /etc/hosts.allow,
>  line 7: missing newline or line too long 
>  Jul 2 07:01:09 BeringFWWeblet sh-httpd[11991]: connect from  
>  216.171.153.130  
 

Not sure on this one, but I will look into it.  There is no end line for that 
file, but 
my entry is probably incorect on syntax.


>As an aside, if I click to see all syslog's, I get an error due to a
>missing gzipped file and nothing else. Should it do that? I can't remember
>what my system at home does!

That is because the file does not exist.  That is an archive file and untill 
the firewall hasbeen running for a while it will not be created.  We could get realy 
fancy and check each file before enabling the link to it, but I think that is overkill 
considering the scall and speed we are already dealing with.  It might make sense to 
place some indication in the response that says more than the current.  Even if it is 
just a footnote.

Richard Amerman

N¬±ù޵隊X¬²š'²ŠÞu¼“†)äç¤Yé\¢g­¢ž’š½éá¶ÚþØbžHzG(›û-æŸuëޖf¢–)à–+--æŸuëޖX¬¶Ë(º·~Šàzw­†Ûi³ÿåŠËl²‹«qç讧zßåŠËlþX¬¶)ߣù^i÷^½é

RE: [Leaf-devel] sh-httpd weblet web-config

[Richard Amerman]

From: Charles Steinkuehler [mailto:[EMAIL PROTECTED]] 
Sent: Tue 7/2/2002 6:33 AM 
>First, a point of order.  In my view of the world, there are two major
>issues currently being discussed:

>- Modifications to sh-httpd (the actual web server) to enhance it's
>ability to be used as the front-end for a web based configuration tool
>
>- The modification, extension, or complete re-writing of the html pages
>and cgi scripts that currently makeup the "weblet" status application
>that currently ships with Dachstein, allowing enhanced web based
>monitoring and even configuation.
>
>I think it would probably help prevent confusion if mods to the web
>server itself refer to sh-httpd, while issues related to making html/cgi
>code to monitor or configure the system use the weblet moniker.
>

I agree completly


>With that out of the way, I completely agree with the idea of forming a
>"group" to work on the weblet portion of the configuration problem.
>This can probably be done with very little effort completely within the
>bounds of the existing LEAF SF project.  With a CVS directory somewhere
>in the existing LEAF tree, folks can share code and updates, and even
>developers w/o LEAF SF developer status can check-out code and posts
>diffs to the leaf-devel mailing list (much like the way the busybox list
>works...I've sent in several bug-fixes to busybox that got incorperated
>into the main code-base, but am not a registered busybox developer).  I
>think the leaf-devel mailing list will work fine as a communications
>mechanism for now, and we can always make a new leaf mailing list if the
>traffic gets too high for the leaf-devel list (unlikely, at least for
>now).

Sounds great.

>On the sh-httpd front, I don't think there will be a lot of work
>required, and sh-httpd is already in the LEAF CVS tree, so probably a
>few leaf-devel posts (and a lot of beta-testing) is all that's required.

>I can commit to help with the sh-httpd mods, and I think I can improve
>the performance of cgi scripts dramatically.  I can probably help with a
>bit of the html/cgi scripting (ie general architecture and maybe solving
>any thorny scripting issues that crop up), but I don't have time to
>commit to a huge chunk of the project.
>
>It looks like Richard's generally headed in the right direction with his
>mods to the existing html/cgi code, especially with the abstraction of
>the content.  Has anyone else made much progress along these lines, or
>should work start on using Richard's framework to start building a
>web-config architecture?
 
One thing I would like to see is for people to realy look at HOW things are 
being done in the current weblet code to offer better ways to accomplish these tasks.
For instance I'm wondering if there is a better way to incert HTML snipits than  the 
cat <<- /HTML
/HTML
Construct.  (Not that I know one, just interested)
 
Also the curent textTOhtml does not deal with indentation of text files well, or at 
all.  This is a problem.
 
Richard Amerman


áŠËë^™¨¥ŠË)¢{(­ç[É8bžAžzEž•Ê&zÚ yé!y«Þžm§ÿí†)äç¤r‰¿±òÞi÷^½éfj)bž   
b²ÒÞi÷^½éeŠËl²‹«qç讧zØm¶›?þX¬¶Ë(º·~Šàzw­þX¬¶ÏåŠËbú?•æŸuëÞ

Re: [Leaf-devel] UML for kernel recompiling

[Jacques Nilo]

Le Lundi 1 Juillet 2002 17:24, vous avez écrit :
> Hi all,
>
> is there a Bering UML image suitable for kernel recompiling?
>
> I'd like to customise a little a Bering installation, but the UML image
> in the Bering download section has an outdated gcc version which is no
> longer supported for kernel recompiling (according to the docs in the
> 2.4.18 kernel tree!).
Luigi:
The UML image in the LEAF download section is indeed a Debian/slink image for 
LEAF developement (glibc 2.0 based) but is not appropriate for a 2.4.x kernel 
compilation (which requires a gcc 2.95.3 compiler of greater only available 
from Debian/potatoe)
Bering kernel compilation is done on a "real" Debian/potatoe machine not a 
virtual one. But there is a Debian 2.2 fs image available on the 
user-mode-linux web site. Check here:
http://prdownloads.sourceforge.net/user-mode-linux/root_fs_debian2.2_small.bz2
You will have to install the compiler on it through standard Debian package 
install.
Hope this can help
Jacques


---
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

Re: [Leaf-devel] OpenSSH security

[Charles Steinkuehler]

> 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.

I vote for running with privilege sepration, and doing whatever is
required for existing systems (ie adding an ssh user, and maybe
including a script to do this for typical LEAF users who don't want to
do it manually).  The ssh user should be added to new distributions.

Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)



---
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

Re: [Leaf-devel] OpenSSH security

[Nathan Angelacos]

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

Re: [Leaf-devel] sh-httpd weblet web-config

[Charles Steinkuehler]

> >On the sh-httpd front, I don't think there will be a lot of work
> >required, and sh-httpd is already in the LEAF CVS tree, so probably a
> >few leaf-devel posts (and a lot of beta-testing) is all that's
required.
>
> IMHO there are 2 issues
>
> 1) the POST/GET functionality must be checked and maybe enhanced

AFAIK, the GET functionality works without issue, but more testing
(especially by someone familiar with CGI behavior) would definately be a
"good thing" (tm).

I have yet to examine the POST patch in detail, but there are no issues
I'm aware of that would prevent sh-httpd from properly implementing the
POST method with nothing but shell-script and common utilities (like
dd).

Another feature for the wish-list is connection-keepalive, which would
help performance (especially with some versions of MS browsers, which
assume connection-keepalive, even if the web server sends a
connection-close).

> 2) authentication may be an issue, but maybe this would bloat weblet,
> especially if we still want to support floppies

I'd prefer to avoid the authentication entirely with sh-httpd, but basic
authentication may be required.  Note that even if implemented, I
wouldn't really consider this amazingly secure...it would simply be a
way to provide some sort of password so Junior couldn't edit the
firewall rules on a whim, enabling the latest [mal|share]ware program to
work.

I think any form of secure authentication, as well as any encryption or
tunneling should be handled by a seperate program (ie ssh, ssl, zeebee,
or similar).

Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)



---
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

Re: [Leaf-devel] sh-httpd weblet web-config

[Erich Titl]

Hi

At 15:33 02.07.2002, you wrote:
>Responses to multiple e-mails rolled into one...
>
>First, a point of order.  In my view of the world, there are two major
>issues currently being discussed:
>
>- Modifications to sh-httpd (the actual web server) to enhance it's
>ability to be used as the front-end for a web based configuration tool
>
>- The modification, extension, or complete re-writing of the html pages
>and cgi scripts that currently makeup the "weblet" status application
>that currently ships with Dachstein, allowing enhanced web based
>monitoring and even configuation.
>
>I think it would probably help prevent confusion if mods to the web
>server itself refer to sh-httpd, while issues related to making html/cgi
>code to monitor or configure the system use the weblet moniker.

Agreed

>...
>On the sh-httpd front, I don't think there will be a lot of work
>required, and sh-httpd is already in the LEAF CVS tree, so probably a
>few leaf-devel posts (and a lot of beta-testing) is all that's required.

IMHO there are 2 issues

1) the POST/GET functionality must be checked and maybe enhanced
2) authentication may be an issue, but maybe this would bloat weblet, 
especially if we still want to support floppies


>It looks like Richard's generally headed in the right direction with his
>mods to the existing html/cgi code, especially with the abstraction of
>the content.  Has anyone else made much progress along these lines, or
>should work start on using Richard's framework to start building a
>web-config architecture?

I only did a few preliminary tests to see if weblet _can_ be used for 
configuration. If POST / GET works with multiple parameters then the rest 
should be quite easy.

my 0.02

Erich

THINK
Püntenstrasse 39
8143 Stallikon
mailto:[EMAIL PROTECTED]
PGP Fingerprint: BC9A 25BC 3954 3BC8 C024  8D8A B7D4 FF9D 05B8 0A16



---
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

Re: [Leaf-devel] Weblet Enhancements

[Charles Steinkuehler]

> > there is a *=* case which resets the parameter list in sh-httpd, it
> > disables constructs like
> >
> > foo=bar&baz=foo
> >
> > I guess parameters without a value would pass fine
>
> Thanks for the detail...I'll see if I can remember why this was
> specifically added when reviewing the code (hopefully sometime in the
> near future).

OK, I dug out my CGI references, and what I have indicates the command
line arguments should only be parsed and provided to scripts if the GET
or HEAD request does *NOT* contain an unencoded equals sign, which is
why the arguments are cleared if there's an equal sign present.

My understanding is cgi scripts recieving data like the above example
via a GET or HEAD request are supposed to refer to the QUERY_STRING
variable, which should be properly exported by sh-httpd.  If using the
POST method, the cgi script will recieve the data on stdin (won't work
with sh-httpd w/o the POST patch).  See the NCSA section on handling
form data with cgi scripts: http://hoohoo.ncsa.uiuc.edu/cgi/forms.html

What cgi programs were you having problems with?  Did they work properly
under another web server (like apache or thttpd), or did you only test
with sh-httpd?

BTW:  The references I'm using for CGI implementations are the NCSA:
http://hoohoo.ncsa.uiuc.edu/cgi/

...and the latest CGI 1.1 internet draft standard I could find:
http://cgi-spec.golux.com/draft-coar-cgi-v11-03.txt

Note there are several more CGI doucments available from the above site,
but I think the 1.1 draft is the most applicable, even though it expired
in Dec, 1999:
http://cgi-spec.golux.com/

Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)



---
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

[Leaf-devel] sh-httpd weblet web-config

[Charles Steinkuehler]

Responses to multiple e-mails rolled into one...

First, a point of order.  In my view of the world, there are two major
issues currently being discussed:

- Modifications to sh-httpd (the actual web server) to enhance it's
ability to be used as the front-end for a web based configuration tool

- The modification, extension, or complete re-writing of the html pages
and cgi scripts that currently makeup the "weblet" status application
that currently ships with Dachstein, allowing enhanced web based
monitoring and even configuation.

I think it would probably help prevent confusion if mods to the web
server itself refer to sh-httpd, while issues related to making html/cgi
code to monitor or configure the system use the weblet moniker.

With that out of the way, I completely agree with the idea of forming a
"group" to work on the weblet portion of the configuration problem.
This can probably be done with very little effort completely within the
bounds of the existing LEAF SF project.  With a CVS directory somewhere
in the existing LEAF tree, folks can share code and updates, and even
developers w/o LEAF SF developer status can check-out code and posts
diffs to the leaf-devel mailing list (much like the way the busybox list
works...I've sent in several bug-fixes to busybox that got incorperated
into the main code-base, but am not a registered busybox developer).  I
think the leaf-devel mailing list will work fine as a communications
mechanism for now, and we can always make a new leaf mailing list if the
traffic gets too high for the leaf-devel list (unlikely, at least for
now).

On the sh-httpd front, I don't think there will be a lot of work
required, and sh-httpd is already in the LEAF CVS tree, so probably a
few leaf-devel posts (and a lot of beta-testing) is all that's required.

I can commit to help with the sh-httpd mods, and I think I can improve
the performance of cgi scripts dramatically.  I can probably help with a
bit of the html/cgi scripting (ie general architecture and maybe solving
any thorny scripting issues that crop up), but I don't have time to
commit to a huge chunk of the project.

It looks like Richard's generally headed in the right direction with his
mods to the existing html/cgi code, especially with the abstraction of
the content.  Has anyone else made much progress along these lines, or
should work start on using Richard's framework to start building a
web-config architecture?

Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)



---
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

[Leaf-devel] RE: [leaf-user] Weblet Dev Demo Update

[Richard Amerman]

Good sugestion on the date time.

Not sure what you mean by with the hosts.allow.  It is suposed to allow everyone to 
the weblet for the demo.

Richard Amerman


-Original Message-
From:   Eyal Lebedinsky [mailto:[EMAIL PROTECTED]]
Sent:   Tue 7/2/2002 1:41 AM
To: Richard Amerman
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject:Re: [leaf-user] Weblet Dev Demo Update
Richard Amerman wrote:
> 
> I have made some major modifications to the LEAF Weblet.  These have been posted to 
>the Weblet Dev Demo site.
> Demo Site Location:
> 207.202.227.167

One thing I have in my weblet, which I see is missing in the
above demo is a standard date/time at the top of each log file.
I find it very usefull to know how old the displayed page is.

And also, do fix your /etc/hosts.allow :-)

--
Eyal Lebedinsky ([EMAIL PROTECTED]) 





---
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

Re: [Leaf-devel] Weblet Enhancements

[Charles Steinkuehler]

> Hi Charles
>
> there is a *=* case which resets the parameter list in sh-httpd, it
> disables constructs like
>
> foo=bar&baz=foo
>
> I guess parameters without a value would pass fine

Thanks for the detail...I'll see if I can remember why this was
specifically added when reviewing the code (hopefully sometime in the
near future).  I do remember I was pretty aggressive on what was *NOT*
allowed to be passed as a parameter, to prevent various exploits
possible via shell-expansion of the cgi command and parameters (ie url's
like http://www.weblet.firewall/cgi-bin/viewlogs&messages;rm+-rf+/ )

Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)



---
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

Re: [Leaf-devel] Weblet Enhancements

[Erich Titl]

Hi Charles

there is a *=* case which resets the parameter list in sh-httpd, it 
disables constructs like

foo=bar&baz=foo

I guess parameters without a value would pass fine

cheers

Erich


THINK
Püntenstrasse 39
8143 Stallikon
mailto:[EMAIL PROTECTED]
PGP Fingerprint: BC9A 25BC 3954 3BC8 C024  8D8A B7D4 FF9D 05B8 0A16



---
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

[Leaf-devel] Re: [leaf-user] Weblet Dev Demo Update

[Eyal Lebedinsky]

Richard Amerman wrote:
> 
> I have made some major modifications to the LEAF Weblet.  These have been posted to 
>the Weblet Dev Demo site.
> Demo Site Location:
> 207.202.227.167

One thing I have in my weblet, which I see is missing in the
above demo is a standard date/time at the top of each log file.
I find it very usefull to know how old the displayed page is.

And also, do fix your /etc/hosts.allow :-)

--
Eyal Lebedinsky ([EMAIL PROTECTED]) 


---
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