Date: Sun, 20 Dec 1998 13:15:33 +0100 (CET) From: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl> To: Andrzej Bialecki <abial@nask.pl> Cc: jkh@FreeBSD.ORG, picoBSD <small@FreeBSD.ORG> Subject: Re: Trinux (+ a proposal) Message-ID: <XFMail.981220131533.asmodai@wxs.nl> In-Reply-To: <Pine.BSF.4.02A.9812191624150.24237-100000@korin.warman.org.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On 19-Dec-98 Andrzej Bialecki wrote: > On Sat, 19 Dec 1998, Jeroen Ruigrok/Asmodai wrote: > >> http://www.trinux.org > > Yes this is very nice set of tools. I'm sure it took a lot of work to > prepare it. Aye... They started in April 1998. So they have come a long way. > Whether we can beat that - well, this would require radically different > approach to our currently used model of crunched binaries. It's clever, > but too limiting. Yeah, and they appear to use three disks and might even go beyond that. Then again as far as I understood the webpage they ain't aiming at embedded systems. More in the low-end on-demand systems as I have been propaganding =P > Recently I was thinking about it and I'm inclined to change this into > something more flexible, something along packages system. Slightly along the modularity concept we looked at earlier? > My idea is to have initially on startup a small (ca. 300-400kB) MFS > containing init and a package handling program. Then, the init would run > the packager, and this in turn would examine the list of wanted packages, > together with their space requirements. Then it would either create > appropriate MFS, mount it let's say on /usr/, and unpack all required > packages into this MFS; or, in case of bigger systems with HDD, just make > sure the required packages are present, and if not - perhaps install them > from some media (like HDD or network, or floppy). That sounds nice. Reminds me a lot of DevFS. Also reminds me a lot like plug-ins. Just a thought, imagine someone replacing a binary with a trojaned version, I think we might need some sort of key system or MD5 or CRC to verify if the correct packages have been loaded. Ways to do that spring to mind: initially don't check until packages are added by a trusted user. Then a CRC-hash, MD5-hash or some sort of other key is generated. Whenever the binary needs to be updated the trusted user needs to recertify the binary or module to make sure the box accepts it. Cumbersome? Mayhaps. Trustworthy and secure? By god, yes. Last thing we need is spamming of bugtraq by some script kiddiez who found holes we could have fixed from start... > Advantages of this model: > > * you're no longer required to have sources for all programs - you need > only to have a small binary package. True, but for the real customizer/developer we still need to set up a framework regarding this new idea. > * you can install only those programs you really want to have on the > floppy. Aye, indeed... Same would go for device driver additions? > * you can easily add/remove components from the system. Based on a security scheme, like the one I presented above. > * it's significantly easier to build bigger systems this way. ("bigger" > means something between picobsd and normal FreeBSD installation) Aye, towards the Trinux idea. This would be real cool. We could with these changes make use of a system that allows micro set-ups to be created as well as larger low-end instant systems. > Disadvantages: > > * all programs will have to be dynamically linked, and ld.so and a set of > libraries must be provided as well. This significantly raises memory/space > requirements. *nods* Surely if we discuss this with some Core members or other developers we might be able to further optimize the dynamic linking stuff? Else we need to start tricking around. And tricking is not a good solution in about 99% of the cases. > * we would need some other (probably incompatible with 'normal' packages) > packaging system. Why? Because it has to contain not only dependencies on > other packages, but also on system libraries (which 'normal' package > system takes for granted), and it should contain space requirements as > well. OTOH, perhaps this can be done using 'normal' packaging - I'm not > sure. Plus if we decide on the security aspect, we need that signing thing of some sort. So normal packaging might suffice, but given the fact that should we settle for an idea like the one I presented we need to make sure the signing gets incorporated in a very secure way and thus needs another package system. Mayhaps Jordan has a few words to spare on this? > Any comments? Hope these helped in a way already =) --- Jeroen Ruigrok van der Werven Pax vobiscum... asmodai(at)wxs.nl Network/Security Specialist <http://home.wxs.nl/~asmodai>; BSD & picoBSD: The Power to Serve <http://www.freebsd.org>; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.981220131533.asmodai>