Re: [leaf-user] Re: [Leaf-devel] Re: Software write-protect (Was: Re: [leaf-user] Floppies)
How about if you modify tinylogin to email [EMAIL PROTECTED] everytime the box is logged into??? -- ~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
Re: [Leaf-devel] Weblet Enhancements
Sorry about my lateness in responding, but I was out of town for the last several days. This post will consolidate reply's from several posts in my absence. Comments are inline ;-) > Security: This is critical if external access is to be provided, but > not really an issue if the internal network is trusted. While SSL > would be ideal for encrpting external sessions, let's not forget > about ssh. If you already have ssh installed, it's possible to tunnel > through ssh to access an un-encrypted weblet running on an internal > private-IP port remotely. This requires ssh in addition to a > web-browser on the remote system, but is quite workable. NOTE: The > Cygwin ssh client from RedHat works just fine for this sort of thing > if you're running a windoze platform. ssh would be ideal, except on floppy images. Maybe zebedee is going to be the best option for remote floppy administration @61KB. See later section. > Funtionality: It would really be nice if the web server supported > the POST method. There is no fundamental reason why you can't do > this with shell-script, and I believe it's already been done. James Sturdevant posted POST support in patch form to the list a while back. I think this will work fine. > Performance: The sh-httpd server is kind of slow when serving up CGI > pages. This is due to the way the shell-script handles spawning the > child CGI process, and checking to see if it's finished. I think > this can be re-architected to perform much better...when I was > working on sh-httpd, I didn't know I could open multiple file-handles > in shell-script, which makes the above problem easier. I don't think much CGI would be required with the use of forms, ash scripts, and limiting access to localhost. > CGI Scripts: Since it's unlikely that LEAF systems will start > including perl, python, or anything similar in the near future > (mainly due to space constraints), I think shell-scripts are the best > choice for CGI's. If there's something that can't quite be done with > sed/grep/dd, I would probably suggest using mawk, which I already > have packaged (required by IPSec), and which weighs in at 45,956 > bytes (compressed). I agree 100% with that statement. I am using forms (of course), which POST on individual lines. I think sed and stock ash are fine w/o needing mawk. The forms would use stock variables (ie... eth0_IP_ADDR) when the "option" sets a single variable and a new variable to set several "stock" variables when applicable (ethernet-dhcp, ppp-dhcp, etc...). The added scripting needed to interpret the added variables would be put in network.conf. As far as changes to the network.conf "standard", I propose modularizing certain sections of declared variables into their own form/conf file, then "sourcing" these new conf files into the "script-only" network.conf file. Example of the break-up of network.conf would be something along the lines of "base-config, advanced-net, qos, and dmz." This will minimize the amount of needed CGI code run. This would also allow for a CLI-config set of scripts so that you can edit all configuration on the LEAF machine itself with the same ash/cgi scripts that the web-based admin uses. Thoughts??? > Modularity: Seems like a good thing! The more flexable the > architecture, the more likely it is to meet the various needs of the > pretty diverse user base we have for LEAF. This will likely be the only way to keep it on a floppy image. This would also help with portability between different versions of LEAF. It would allow for saving each "module" individually, so that small changes would use minimal resources and accidental errors would be less of an issue. We could also add a link to a "config-barf" CGI file that could auto-magically post comments+config information via a web-form to the mailing list. My use of starting with DF is simply that I am very familiar with the release and my lack of knowledge with Shorewall. Bering would likely be easier to work with, however most code should be relatively portable with variable & conf file name changes. I expect with the amount of people that are willing to work on this, that parallel development between releases will be no problem. Scott, I love your idea this would be beautiful in environments that would have a server available However, a huge amount of our users will not, so we are simply working around the requirment of hand editing configuration in a minimal amount of disk-space. I'm hoping something that is stand-alone on a floppy is possible. At 10:31 PM 6/26/02 +0200, Erich Titl wrote: >I am playing around with weblet to get some kind of a web based >configuration. Authentication is certainly an issue there and I am very >interested in anything that should come up in that aspect. Let's consider this. only a certain set of machines *should* be allowed access to configuration period. Weblet/sh-httpd allows for setting allowed hosts in the present configuration an
[Leaf-devel] Re: Software write-protect (Was: Re: [leaf-user] Floppies)
Jeff Newmiller schrieb: [...] > I think the executables-only-on-read-only-mounted devices idea has merit. > I am, however, somewhat bothered about having to reboot into an alternate > excution environment before making configuration changes because of the > usability factor... only a very small minority of people putting together > a new LEAF box could do it without testing on the fly. Write-protect is a > very simple, direct solution to this problem, while your option has > potential to be rather operator-unfriendly. That's right, in the meantime I have abandonded the idea of booting to another runlevel, but I see no way to avoid rebooting to remove the write protection. This is inherent to this principle. There will be a list of files that must be writeable so the user can decide what will be configurable on the running system. Another option is to configure the system without using the wp package. There will also be the possibility to decide at boot time to use the write protection, with a configurable timeout to allow unattended reboots. [...] -- Manfred Schuler E_Mail: mailto:[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
[Leaf-devel] Re: Software write-protect (Was: Re: [leaf-user] Floppies)
I fail to see any benefit to using software write-protect when hardware write protect is convenient, easy and fool proof. Simply move the write protect tab into the protect position and its done. The only way to unprotect it is to physically move the tab back to the writable position. That can't be compromised without physical acess to the disk. Frank Kamp --- 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: Software write-protect (Was: Re: [leaf-user] Floppies)
On 30 Jun 2002, Mike Noyes wrote: > On Sun, 2002-06-30 at 05:07, Manfred Schuler wrote: [...] > > Also I am a little bit astonished as all people > > on the list agree that any additional level of > > protection is an improvement. But in the discussion > > about software-wp people argument as if it would > > make things worse. > > We've lived with hardware write-protection for a long time, and we know > it works. There is usually resistance to change, but it's rarely > insurmountable. I think the executables-only-on-read-only-mounted devices idea has merit. I am, however, somewhat bothered about having to reboot into an alternate excution environment before making configuration changes because of the usability factor... only a very small minority of people putting together a new LEAF box could do it without testing on the fly. Write-protect is a very simple, direct solution to this problem, while your option has potential to be rather operator-unfriendly. > > I still think it is an improvement of security to > > protect the ramdisk and to restrict access to the > > boot device as far as possible. This increases the > > required skills of an intruder and also the chances > > to detect an intruder. > > If you check the mounting options of the ramdisks > > every second, an intruder has only one second to > > compromise the system and to install and run the > > tools to hide the intrusion. > > > > The protection can completely be done in a package. > > A few changes (make /var a seperate file system, > > separate mount from busybox) in the base system > > would make things easier and do no harm to the > > system. The user can then decide to use the package > > or not. > > > > I'm short of free time at the moment, but maybe in > > the next weeks I get the occasion to make a > > beta-version of this package. I will post then the > > information on the list when it is available. > > Please do. It's always worthwhile to look at new ideas. Please post your > package information on the devel list when it's ready. I, too, will be interested to see if my concerns are unfounded. :) --- Jeff NewmillerThe . . Go Live... DCN:<[EMAIL PROTECTED]>Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --- --- 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: Software write-protect (Was: Re: [leaf-user] Floppies)
On Sun, 2002-06-30 at 05:07, Manfred Schuler wrote: > I followed the threads on hardware-wp. The last > information I read was that you have to do some > SMD soldering to get the write protection feature. > I think that this is not well suited for many > people as you need some soldering experience to > do this. Manfred, You are correct on both points. > The last information i got from apacer is that > it is possible to write protect the device, but > they don't sell devices with write protection as > there are not enough customers to request this > feature. I believe Apacer is talking about the version with the zero ohm resister build time option enabled on the ATA-Disk Module. I have the standard version without the build time option. My father and I are going to attempt post purchase modification of this module to enable write-protect. > Also I am a little bit astonished as all people > on the list agree that any additional level of > protection is an improvement. But in the discussion > about software-wp people argument as if it would > make things worse. We've lived with hardware write-protection for a long time, and we know it works. There is usually resistance to change, but it's rarely insurmountable. > I still think it is an improvement of security to > protect the ramdisk and to restrict access to the > boot device as far as possible. This increases the > required skills of an intruder and also the chances > to detect an intruder. > If you check the mounting options of the ramdisks > every second, an intruder has only one second to > compromise the system and to install and run the > tools to hide the intrusion. > > The protection can completely be done in a package. > A few changes (make /var a seperate file system, > separate mount from busybox) in the base system > would make things easier and do no harm to the > system. The user can then decide to use the package > or not. > > I'm short of free time at the moment, but maybe in > the next weeks I get the occasion to make a > beta-version of this package. I will post then the > information on the list when it is available. Please do. It's always worthwhile to look at new ideas. Please post your package information on the devel list when it's ready. -- Mike Noyes <[EMAIL PROTECTED]> http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- 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
