Hello all,
>Message: 4
>Date: Tue, 19 Feb 2002 23:20:07 -0600
>From: David Douthitt <[EMAIL PROTECTED]>
>Subject: Re: [Leaf-devel] Re: Standards and due process :-)
>To: LEAF Development <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>
>I was thinking...
>
>If you make root.list contain specific files, and "move" the
>specification of "./" to another package, that raises some interesting
>things....
I think you are beginning to see the benefits.
>What if instead of gloming onto home.lrp, you create
>overflow.lrp or default.lrp?
>
>One nice benefit would be that if that package grows, one would KNOW
>it.... and the root.lrp package in systems that still use it would not
In all kindness, please use the setup that is most confortable for you. As
soon as you move "./" out of the RAM disk, you get all kinds of benefits.
>> 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.
>
>Oxygen already supports the use of config.lrp, which is a package
>containing ALL files listed in *.conf files and saved in package
>format - and this package is loaded *LAST* after all other packages.
>
>This means that you can update the conf files and then save them to a
>floppy which is used during a CDROM boot - in which case your
>configuration is used and the system is configured just how you want
>it.
As a scientist, curiosity often gets the better of me :-). The text you are
quoting from my post to Charles is an hypothesis formulated in three parts.
It does not offer any factual information and it does not contain any value
judgment on anything. Are you giving an example where files are dynamically
stored in a package other than their package of origin? Is the intent of
your post to demonstrate that Oxygen already has a default store, albeit one
reserved to *.conf files?
>Message: 3
>Date: Tue, 19 Feb 2002 22:57:13 -0600
>From: David Douthitt <[EMAIL PROTECTED]>
>To: LEAF Development <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>Subject: [Leaf-devel] Default Stores, ash, etc.
>
[snip]
>
>Adding a NEW package with the entry "./" in the new Oxygen environment
>(which uses root.gz) would be interesting. It basically means you can
>extend the base without having to create packages or other things.
>
Correct. This can be done in any arbitrary way you see fit. For example, the
code in the discussion floppy can mount up to 10 arbitrary directories,
which means that you can replace /sbin on the fly, among other things. For
another example, the user can drop files in your enclosure and reuse the
ramdisk for something else. I am sure you can come up with examples of your
own.
[snip]
>There is a number of other mail scripts (including the LRP original,
>and one by Mike Sensney) - but all of the scripts use that minature
>nc.
>
Thank you. To answer one of Michael's question, that "miniature nc" has
enough power to create havoc on a network if an intruder gets in the box. At
one point in time, netcat was the utility of choice for hackers and
sysadmins alike. I will create a small script to replace the subset of
Charles's mail command that is used by multicron-d.
>Message: 5
>Date: Tue, 19 Feb 2002 17:56:04 -0600
>From: "Michael D. Schleif" <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>Organization: mds resource
>To: Serge Caron <[EMAIL PROTECTED]>
>CC: [EMAIL PROTECTED]
>Subject: Re: [Leaf-devel] Re: Standards and due process :-)
[snip]
>
>Isn't an exhaustive list of required files a de facto standard?
>
>Message: 6
>Date: Tue, 19 Feb 2002 18:20:38 -0600
>From: "Michael D. Schleif" <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>Organization: mds resource
>To: Serge Caron <[EMAIL PROTECTED]>
>CC: Charles Steinkuehler <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
[snip]
>
>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.
>
To reduce two great posts to these two small quotes is really a shame. In
all fairness, on this show you get all the time in the world to tame your
lions :-).
Delivering a predictable system does not require to go to such extents as to
redefine what amounts to a way of life for millions of people.
We want to offer a system based on a model in which components are
distributed from a variety of sources (LEAF, developers, repositories,
clients, etc). We also want this system to be somewhat predictable, if not
completely predictable. Finaly, significant standards are out of our grasp:
the Linux kernel will stay the way it is and so will the various boot
loaders.
We can start managing things with the initial RAM disk. The convention that
I use is simple: this RAM disk should contain a manifest indicating the
EXACT contents of the RAM disk, including the manifest itself which is
stored in var/lib/lrpkg/<ramdiskname>.list. This list should be unambiguous,
eg, there are no wildcards in the list entries. (Such as the list
enumerating the contents of the Oxygen 1.9 ramdisk submitted on Feb 19).
Please contrast this with your question "Isn't an exhaustive list of
required files a de facto standard?". The "standard" here is A) to provide a
manifest under the name var/lib/lrpkg/gizmo.list if your ramdisk file is
called gizmo.lrp and B) that this list be an exhaustive enumeration of the
files (regular,block,character,links,etc) on this RAM disk.
There are NO required files. Ergo, there is no baseline. It is unimportant
how the designer of this RAM disk will manage the bring the system up and
load the other packages. Nobody else than LEAF will bother to load these
packages and create a running system. So, our base component is this RAM
disk, a life support system that I call an enclosure.
v5.0.4 of my enclosure validates packages in two significant ways:
A) it enumerates the files that will be replaced by a package (right now it
displays a message like <package>: 9 file(s) 1 symbolic link(s) replaced
from /dev/fd0u1680)
B) it displays all the orphaned files in the package, eg, it displays the
filename of anything NOT contained in the package manifest
(var/lib/lrpkg/<package>.list)
Part A) above implies that I can build an audit trail of all the files
replaced during the entire boot sequence by, for example, creating
directories var/lib/lrpkg/dir<n> and moving there candidates for oblivion
:-). In other words, I can enforce policies at the end of the load sequence
:-).
Part B) above implies that I can detect malformed or malignant packages, eg,
package replaces passwd file or some such thing without claiming the file in
its manifest (var/lib/lrpkg/<package>.list).
If you have followed closely, it is now possible to build dynamically an
exhaustive list of the system contents up until the point that /sbin/init
receives control. This list could contain significant data such as MD5
digests or anything else the end user may choose, depending how they view
their intrusion detection system.
Please understand that we have this precise control without having to "agree
on silly little things like location of configuration files" as you say.
This result is achieved by following three conventions:
1) packages can store files anywhere in the filesystem with the exception of
var/lib/lrpkg which is subject to a naming restriction;
2) packages can only store files in var/lib/lrpkg with names of the form
<package>.<any other string> Non conforming packages are skipped.
3) packages may not contain files named
var/lib/lrpkg/<package>.{anything.}links Non conforming packages are
skipped.
Clearly, LEAF is designed to allow packages to overwite each other's files.
Convention 1) above says anything is FAIR GAME except the contents of this
directory. So nobody will overwrite your package manifest (Convention 2)
above) and your package contents is not destroyed if somebody takes a backup
of your package. This also gives enclosures a "safe" write enabled storage
area which means that if a baseline file is being built, it will not be
replaced by a malignant package. Please note that this is a concept: I did
not go to the trouble of checking for new symlinks to var/lib/lrpkg and
other games _I_ could play. It is a sane concept at this point, that's all.
These two conventions EXPLICITLY avoid any type of specifications for
avoiding "overlapping" packages as Charles says. If you design an
iptables.lrp package and Jane Doe design an iptbl.lrp package with 90%
overlap, so be it! Nobody owns anything and the load order determine which
contents stays on top. The load code can tell you that this is the case and
it is possible to implement a form of overwrite protection. However, the
intent is to trace each file in this file system from the time the load code
receives control from the kernel to the time when it returns control to the
kernel . This includes "deleted" files and it is possible, for example, to
compute an MD5 digest taking into account these deleted files which means
that it would be IMPOSSIBLE to reproduce this digest once the machine is
running. So, if you build a system in a secure area and compute this digest,
simply computing it again at boot time and displaying the signature will
tell you right away if the system has been tampered with.
Convention 3) makes sense only to those that know the LEAF backup code.
Since early LRP days, these files have contained enumerations of symbolic
links to specific programs: root.bb.links for symbolic links to
/bin/busybox, root.pn.links for symbolic links to /bin/POSIXness, and the
like. The backup code append these enumerations to the global exclusion list
so that these entries are excluded from ALL packages AND the enclosure.
Preventing these files obviously protects the enclosure (the package can
already exclude anything with a file <package>.<something>.list). However,
we can now build a DYNAMIC exclusion list at backup time by selecting ONLY
those entries in these .links file that are still symbolic links at backup
time.
The benefit here is that we have some redundancy (a FLOATING baseline :). If
anybody drops a file in any package (or in the enclosure) for which there is
an entry in one of the .links files, the FILE is NO LONGER EXCLUDED when the
package or enclosure is saved. As long as the file is enumerated in the
package or enclosure manifest, the functionality from this file will replace
that of the linked file.
For example, the busybox binary can contain halt, klogd, etc applets (with
corresponding entries in busybox.links) and the user may extend the base
system by simply dropping the real halt and/or klogd binaries in the
enclosure OR IN ANY OTHER package. Conversely, a package that insists on the
real xyz (or a specific revision of such), for example, could include the
utility with its own files and not break anything.
Think of it this way: there can be a miniature sed during the time packages
are loaded and a full blown gawkish monster available by the time the
startup script for you package is started. Unlike the present situation, the
monster does not have to be part of the enclosure: you can have a measure of
redundancy that allows the enclosure to use busybox sed, for example, until
such a time that the real thing is loaded whithout having the enclosure
claim to be the exclusive residence of sed.
v5.0.4 innovates in detecting the shell under which it is running. It is a
lttle bit more pro-active. We are still mostly talking ash and busybox ash.
However, it is no longer a requirement to place a system wide available
shell in the enclosure.
As noted before, v5.0.4 uses .links files in a slightly different way.
First, these symbolic links are created in the order the links files are
enumerated (there is a links= parameter on the command line since v5.0.0
that has a semantic similar to the LRP= parameter). So, these links are
enumerated in a predictable manner: should there be two entries with the
same name, the last one has precedence over the other. Therefore, the final
result is always predictable and under the user's control. The busybox in
v5.0.4 contains halt, poweroff, and reboot applets. The enclosure contains
the real halt binary and halt.links which contains entries for
/sbin/poweroff and /sbin/reboot. Because halt.links is processed after
busybox.links, poweroff and reboot will use the real halt and those in
busybox will be ignored.
Had you wished to make a halt package, the manifest var/lib/lrpkg/halt.list
would contain four entries (sbin/halt, sbin/poweroff, sbin/reboot, and
var/lib/lrpkg/halt.list). In either case, the correct stuff goes to the
correct package in a backup operation.
As you can see, a very limited set of conventions that do not impact the
existing base can bring a sense of order and security for specific
operations. Once the system starts running, only YOU as the user know what
the sum of all these LEAF components do. From there, you can follow the lead
of anyone that makes an intrusion detection system or you can write your own
policies. You are the master of your own appliance... :-)
There are now two discussion floppies:
http://leaf.sourceforge.net/devel/scaron/discussion3.img and
http://leaf.sourceforge.net/devel/scaron/discussion3static.img
The former has Debian ash and the later has Oxygen 1.9 busybox ash. Both
have alternating kernels, alternating modules, and space enough to try some
of your ideas.
Please note that busybox.links in the static version still has to be edited
to remove the /bin/ash entry. This will not be necessary in v5.0.5 and it
will be possible to drop completely arbitrary busybox configurations in the
enclosure. How low can we bring this baseline?
Regards,
Serge Caron
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
