Hello Lynn A few notes to think about . - on the security issue we agree.
What I wanted to do was to keep the possibility for users to keep to the original way of modifying. ( plain txt editing) This made it more difficult to parse such files, but also more flexible. If they inserted a comment it wasn't removed. The solution you suggest is about the thing Suse for example uses for its distribution. A parseable txt file with a style like var1="aasdf" var2="sssdf" etc. The problems appear if you did edit a programm manually, for example to insert an option that the programm (that is to configurate) knows off. but the configuration script doesn't allow. What to do if a user inserts a comment in a configscript ? Useing a nonstandard programm. for example to update a dyndns or ipsec with or without certificates what is included in the general config file and what isn't ( I think that is the central question ) What I wanted to do is merely to present a set of routines to show a page, that you could easily adapt yourself. ( kind of mini php script :) ) The weblet doesn't necessarily have to run as root, as long as reading and writing is done suid root. 2. The suid root read and write routine is only a limited security issue. If someone hijacks the box and can act as user sh-httpd or whatever with writing access to /tmp . He could copy or create a file /tmp/someconfigurationfile and this was with root rights written back to the place it had to be. This was only ment as friendly side notes. Regards Eric Wolzak member of the Bering Crew > As I noted, this post is to submit where I am with the > roadmap towards a new configuration system with > an available web-based front-end (optional). > > First of all, this is an idea that I am sure several people > on the devel-list don't wish to participate in So if possible > please add the [config] sub-Subject in posts on this subject > so list-members can selectively disregard the topic easily > if they wish. TY > > Second, what I am suggesting is not entirely functional on my > system at this time. What successful testing I do have is > very similar to what Eric has made available. I hope to > have tested and made available something closer to what > I am about to describe within a week or so. > > This being said, I'll get into some actual substance now. > What was last agreed on when the topic was last actively > discussed was along the lines of this: > > 1) A new back-end (actual configuration, backup, etc...) was going > to be needed. There is not a variant out there that doesn't have > some of the same information in several places/packages as Eric > has stated. A good example of this would be interface/network > ip information, hostname, package-name information, etc.... which > affects the core of a working system. There are two approaches > to working with this: Either we can set the backend to modify the > same information in 'x' number of places that are not necessarily > known or we can save this information in a file of set of files that > can be used by anything needing this information. The latter option > would break drop-in compatibility and reworking existing packages, > but would allow for easy portibility between different variants if desired. > The latter option was also what was earlier agreed on, as was the > use of Bering for testing since Bering is the lead into the future of LEAF > variants. > 2) The back-end will not depend on any one front-end application. > Although a web-based front-end has been a highly-desired feature, > there will always be a higher security risk involved with the inheirent > protocol(s) used. Many people will always use a script or hand-editted > configuration system when available, so it would be necessary to allow > the front-end itself to be modular with ideal options of configuration by > http(s), CLI-script, hand-editting, and/or CLI-menu systems using the > same core back-end. > > 3) If using the web-based front-end, integrating atleast one optional form of > authentication/encryption for any un-trusted access (WAN or LAN). Although > OpenSSL/SSH would be the ideal method, SSH alone won't fit on a standard > single floppy Bering image; I suggest adding the capabilities of tunneling > through zebedee and/or stunnel as smaller, feasible alternatives. > > 4) Package modification will have to be made to maximize the use of a newer > more advanced configuration back-end. Many discussions have passed over > a feasible alternative to the standard '*.lrp' format including the *.udeb > and *.ipkg formats. Ipkg is a small replacement for Debian Dpkg and > works with any .[x}deb packages, so I personally could see it as a valuable > addition to the back-end application as well. Mandatory additions to > any packaging format could include a parsable file list, any package-dependant > scripts or http/cgi/menu files, and a dependancy list. > > 5) Package loading, saving, backup, and installing. 'lrpkg' can now be > considered quite limited in the desires and demands of the present > day OS's. The only easily feasible alternative that I am aware of for > LEAF would David D.'s 'apkg' system. Alternatives to 'apkg' would > need to be built from the ground up in the back-end, so I can provide > a few idea's if anyone want's to play with them. Ipkg, as mentioned > before, provides easy loading/unloading of packages from *any* source > and uses a standard and flexible package format that has been well > tested, however there are not many options for configuration and none > for backing up a package in the scope of LEAF. > > 6) Use of compiled binaries in the configuration system has been discussed > before in regards to back-end programs, boot-management, and CGI. As I am > not much more than a familiar "interpreter" of C, Jscript, xForth, etc... > I don't plan on digging too deep into this topic since there are many others > in the development team that are far more qualified to suggest an opinion > than myself. > > *) Back to the web-end topic. I have been playing with this idea: > > http -> cgi-sh -> read-running-config > -> /tmp/config.files > -> verify /tmp/config.files > -> call suid-C binary to save new-configuration > -> call suid-C binary to backup new-configuration > > 'new-configuration' in the core system would be a file or set of files > that would be source-able by any existing conf file through variable > substitution of the present conf files. Any package should be modified > to add the necessary 'new-configuration' file and variables in the > existing conf file(s). > > *All untrusted http should be encrypted and authenticated. > *http and cgi does not run as 'root' or over-write configuration itself. > *All over-writes are done by a suid-C binary like 'su-wrapper'. > *All front-ends and packages should be 'modular'. > *Since new and different necessities will be needed from the > packages themselves, dedicated binary download trees should > be available. > > I'm done for the moment.... the brain is now somewhat fried! ;-) > Thoughts, comments, suggestions, or flames??? > > -- > ~Lynn Avants > Linux Embedded Firewall Project developer > http://leaf.sourceforge.net > ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
