Linux - an idea for more flexibility and security.

[stemsee]

I don't really like that there are more than one bin and sbin directories. But just linking the others to the /bin and /sbin poses problems.

I have this idea of managing directories in a slightly unorthodox way.

My idea is that we start with the / and its directories /bin /etc /lib /lib64 etcetera. But from then on we only use discrete savefiles named accordingly to mount on those / dirs. Also in for example sbin.4fs there is also a nested sbin.4fs which mounts on /usr/sbin. And all subsequent sbins are nested in parent sbin.4fs.... likewise for all other duplicate dirs. That takes care of backward compatibility.

This is more similar to a full install, and the savefiles can easily be resized, and managed and swapped with versions/snapshots.

I like the idea and I hope to have a working proof of concept soon. It will require a new init. Also all parts of the system can be stored anywhere, usb sticks, network storage, ntfs, fat32, encrypted individually etc .... who could hack it?

stemsee

[Moose On The Loose]

I don't really like that there are more than one bin and sbin directories. But just linking the others to the /bin and /sbin poses problems.
[...]

I think I see your point and it may be a good one.
You may want to start with creating a directory on the host machine for the save files to all live in.
You can then make a subdirectory of that one as a place to keep previous copies so that the user can save a copy before they install the next thing.

As it is, puppy is very secure partly because it is not like the systems that are commonly targeted and partly due to its nature. Keeping all the save files on a memory stick in your pocket is a good way to not have someone mess with the save files.

[bigpup]

[rufwoof]

The different folders exist in part for security reasons. Each extra line of code is a potential security risk (might contain a bug that could be exploited to circumvent security). So in the initial boot phase you only want the minimum bin/sbin ...etc. files/folders available. At a later phase of the boot sequence so other bin/sbin files (folders) are pulled in. And then once booted, user/site bin/sbin files might be added separately at different sites (usr/local/bin's ..etc.).

When a single site/user however, and given standard usage of root userid, its much less of a issue. But even then there may be times when the user still wants the additional separation. One of my boots for instance is just 11MB in size combined vmlinux/initrd - that lowers the potential attack vectors to a minimum. But such requirements/need are very low nowadays.

I did at one time ponder a similar arrangement of using multiple sfs's separated by folders/content. home.sfs, root.sfs, etc.sfs ...etc. as that way you can reform a sfs (with its changes) quicker than having to reform a entire single (large) main sfs. Handy also if you also only want to save some changes, not others. I posted this earlier which is yet another variant http://murga-linux.com/puppy/viewtopic. ... 90#1040290 where changes are stored back to the main sfs in a manner that (mostly) avoids having to rebuild the entire sfs to incorporate changes.