FreeBSD as read-only firmware
Mehmet Erol Sanliturk
m.e.sanliturk at gmail.com
Sat Nov 3 15:01:10 UTC 2012
On Sat, Nov 3, 2012 at 6:34 AM, Alexander Yerenkow <yerenkow at gmail.com>wrote:
> 2012/11/3 Lev Serebryakov <lev at freebsd.org>
> > Hello, Alexander.
> > You wrote 3 ноября 2012 г., 16:14:21:
> > AY> Hello all!
> > AY> Some time ago I got somewhere idea, that base OS should be RO -
> > readonly.
> > AY> And should be updated easily (ACID) and with possibility of fast
> > rollback.
> > Why it is better than nanobsd?
> Of course, that's all IMHO and fit for my usage:
> 1) Same FreeBSD, as in laptop/desktop, (e.g. really same - GENERIC kernel
> is used, without dropping any kerberos or else), and yes, I know that
> nanobsd can that;
> 2) .vmdk simply deployed into Esxi/virtualbox (not sure nanobsd can produce
> 3) Transparent /etc/ modifiying VS nanobsd approach (edit, don't forget
> mount /cfg, copy there;)
> 4) Only OS, no packages included - e.g. I can upgrade/downgrade packages
> without touching any byte of OS. Except for symlinks :) nanobsd specified
> that if you want packages - you need built them in.
> Of course differences not so big, and I'm not saying that my way is more
> It just raised question deep in me - why OS still aren't modularized, and
> most of it not in RO (while it should).
> Something like this
> > --
> > // Black Lion AKA Lev Serebryakov <lev at FreeBSD.org>
> Alexander Yerenkow
One of my goals for the FreeBSD usage is as follows :
Search all of the FreeBSD sources for the file opens and write statements .
Divert all of the file opens and write statements outside of FreeBSD base
for example into /var .
Modify base to prohibit any load of executable from /var , and /tmp , and
other directories which are not included into "base" part .
Select a primary collection of packages . Divert all of their file opens
and writes to /var .
Make /home a separate partition , not included into /usr .
For any user , if it is selected , allow his/her home unit definition in a
removable drive .
Prepare a list of programs which can only be executed by root , and move
them to a root
allocated directory , and make this list a reserved names list . Do not
allow any user to execute
these programs whether they are supplied by themselves .
In a similar way , make a list of executable programs for the "base" system
and "packages" in the "base" part , make them "reserved" names and do not
allow any other program with the same name .
Delete from the base system the "PATH" concept , and require that all of
names are supplied by complete path . If access privileges of a directory
is not **x|**x|**x
do not allow any program to be executed from such a directory ( recursively
from its sub-directories ) .
At present , file access privileges should be ***|***|**x for searching
This definition is causing security vulnerabilities for directories because
it is exposing it to
"OTHERS" . Convert all of the parts requiring ***|***|**x to r**|r**|---
for directory searches .
In that way , if the user is defined in that way , prevent others to
access to a directory and make this as default .
Record "base" part into a SDHC card and make it "write protected" .
Prepare the "base" SDHC card in a computer that is NOT connected to a
network and it is physically protected from intrusion .
When a change is required , prepare a new SDHC card in the clean computer
and use the
new SDHC card .
Replicate SDHC cards as many as required for different computers .
In that way , there will be an impenetrable system which on boot we will
know that it is clean .
There a some live CD/DVD compilations , but they are not usable for
because they are not designed in that way .
For such a work , the best one with respect to my opinion , is
among other live CD/DVD compilations . I did not try that one in a SDHC
I do not know exact data transmission rate of SDHC cards , but , I think ,
it is faster than CD or DVD . For CD and DVD , at present there is NO any
only READ CD or DVD devices . They are disappeared from the market . For
writable CD or DVD , it may be possible to append some files at the end of
recorded area , and the media may be corrupted by re-recording ( I think ) .
Thank you very much .
Mehmet Erol Sanliturk
More information about the freebsd-current