RE: [Leaf-devel] Web-config devel
Lynn, I completly agree with all of your points, no nead to be spacific. I am too new to the group to make any major sugestions to procedure. Most all of my changtes were just to the normal weblet as it is/was. I do believe that the modulerization and code cleanup I did should help support the configuration project unless we decide to completly change things. Much of what I did uses the existing methods so their may be better ways to do things. I think it would be good to replace the texttohtml function with a better one. See the source code printout at the Dev Demo site to see what I mean. Richard Amerman -Original Message- From: guitarlynn [mailto:[EMAIL PROTECTED]] Sent: Mon 7/1/2002 10:32 PM To: [EMAIL PROTECTED] Cc: Subject:[Leaf-devel] Web-config devel As stated before, there appears to be several people doing preliminary work on modifying Weblet to be used as a web-based configuration tool in the LEAF community, but not limited to the LEAF developers. It would be safe to assume that at some point redundant work will be done to achive the same end result. It would seem to be logical to form a consolidated group of developers to work together on this project, so that 1) development would be faster, 2) each developer could focus on a particular piece of the code, 3) the finished product would likely be better and more portable in respect to LEAF itself. How (and if) a group to develop a web-config package should be formed and run within the LEAF site is questionable and any idea's and advice is appreciated for a direction to take. At the moment, the work that has been done has been considered to be an extension of the weblet package and/or sh-httpd. Personally, I find a Web-configuration product to be something that is it's own entity, and be treated as such even though extensions will be made to the present sh-httpd code and integration with weblet will be a safe assumption. Shell/CLI environment configuration will need to be availible and the finished package should be optional as a package to the LEAF release(s) used on. I think a dedicated CVS branch, a means of communication, a schedule, and a roadmap would be general requirements to a clear and efficient development cycle for such a project. Is there an existing way to do and or all of this within the present LEAF infrastructure? Thoughts??? -- ~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 Welcome to geek heaven. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel --- 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 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]) http://samba.org/eyal/ --- 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
Hi Charles there is a *=* case which resets the parameter list in sh-httpd, it disables constructs like foo=barbaz=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
Re: [Leaf-devel] Weblet Enhancements
Hi Charles there is a *=* case which resets the parameter list in sh-httpd, it disables constructs like foo=barbaz=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/viewlogsmessages;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
[Leaf-devel] sh-httpd weblet web-config
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
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]) http://samba.org/eyal/ --- 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
there is a *=* case which resets the parameter list in sh-httpd, it disables constructs like foo=barbaz=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
Re: [Leaf-devel] sh-httpd weblet web-config
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] sh-httpd weblet web-config
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] OpenSSH security
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] UML for kernel recompiling
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
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. snip 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] sh-httpd weblet web-config
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 pre.../pre), or maybe code.../code 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 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
[Leaf-devel] [ leaf-Patches-576599 ] ip-graph
Patches item #576599, was opened at 2002-07-02 14:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=313751aid=576599group_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=detailatid=313751aid=576599group_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
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
Re: [Leaf-devel] sh-httpd weblet web-config
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: snip 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] sh-httpd weblet web-config
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] OpenSSH security
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 mods
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
Nathan Angelacos wrote: On 1 Jul 2002 at 22:38, Greg Morgan wrote: snip Long answer: According to http://marc.theaimsgroup.com/?l=openssh-unix-devm=102495293705094w2 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
