Serge Caron wrote: >
[ snip ] > In the long term, I want to be able to run from "secure media". In the short > term, I use CD for write protected storage and floppy for write-enabled > storage (wich I write-protect between sessions :). Suppose a package > designer stores something in /etc/mypackage (which is either a file or > directory, your choice). This designer has many choices: > 1- claim /etc/mypackage as part of this package > 2- rely on an unwritten standard or tacit convention that /etc belongs to > another package (presumably etc.lrp) > 3- rely on the user's knowledge of the LEAF standard that his file will end > up in the default store. > > If /etc/mypackage is also a directory, the package designer can "optimize" > the backup operation by omitting certain temporary files (enumerated in > xyz.anything.list). > > Suppose that the system of partial backups is finely tuned so that modified > files always end up in write-enabled storage. Suppose also that packages > from read-only storage are always loaded before packages from write-enabled > storage, eg, you don't loose modifications. Finaly, presume the goodwill of > the package developer, eg, package xyz claims nothing out of its immediate > territory. > > This above set of conventions places the entire burden of protecting this > package in the hands of the package designer with no support from the LEAF > appliance it is supporting or the user operating the machine. This is > precisely Michael's line of questioning. If there is a standard, then the > user knows what is going on and backup is one of the user's many > responsibilities. However, we all know that history has been written before > us and that pppd uses /etc/ppp and dhcpd uses /var/state, etc: addressing > the problem from this angle IS next to impossible, especially if we try to > make a sysadmin out of the user. Yes. Again, that a system successfully boots up is great! That I know what to expect in a system long after bootup is quite another thing ;> Perhaps, once we understand how the system works, it might be possible to agree on silly little things like location of configuration files. If it contributes to better system performance, better system security, &c., perhaps it may not be out of line to suggest that /var/state/dhcp be a symbolic link to /etc/dhcp? Such a thing is trivial to a package developer; but, no such step will likely be taken, unless there is some convention that lends credence and bestows value to this decision. > This user is also subject to constraints of his own. The readme file in / > stating that trespassers will be prosecuted to the maximum extent of the law > is a real life example. The file belongs to the user and even he can't > choose the location. Another example is dropped files. You and I may find > that dropping /var/run/xyz.pid files is OK. Unfortunately, it does not match > many audit policies, including those of my organization. > > None of these things are issues if the filesystem is persistent storage such > as hard disk. When it is not, you have to expect that somebody else than > LEAF will select which files goes to write-enabled storage. As of now, I am > doing OK by rewriting most lists (on the fly!) and saving the default store. > > This system is far from perfect and this is why I am supporting Michael's > quest :-) Building on your notion of ``unambiguous enumeration'', let it be said that the more that we know about a running system, the more that we understand the processes in motion that comprise that system, the more secure we can be. What is security? Part of it is knowing that a system is performing according to a specific set of specifications. Knowing which files, in what state and allowable contents, &c. we should expect on the running system is, itself, a specification. As such, that specification is also a standard by which we can measure such interesting Events as system load, performance, intrusion, &c. [ snip ] > I am less excited by the building of the LEAF components themselves at this > point (No! I do NOT like Red Hat 5.2 :-). I am certain that we can come up > with an unambiguous way of specifying the whole system, even if we have to > point out all the gotchas one by one. Then I will be excited for anything > else I can put in there :-) Once we arrive at this ``unambiguous way of specifying the whole system'', then we have blown the lid off of previous limitations. Developers can concentrate on creating packages even better suited to the LEAF environment. As it is, we grab some off-the-shelf source, compile it on our slink over there in the corner and figure out how to shoehorn it into an LRP file. There is much more that many more people can do to contribute to the greater good of this project, once the system is understandable to outsiders . . . 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 . . . _______________________________________________ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
