FreeBSD as read-only firmware

[Alexander Yerenkow]

2012/11/3 Mehmet Erol Sanliturk <m.e.sanliturk at gmail.com>

>
>
> On Sat, Nov 3, 2012 at 9:08 AM, Alexander Yerenkow <yerenkow at gmail.com>wrote:
>
>> Actually in my case, base system image r24243.vmdk, have exactly two
>> partitions (gpt's freebsd-boot, and roots = freebsd-ufs), and second one is
>> used only in read-only :)
>>
>> For virtual machines approach, base image can be even ISO, which will be
>> implied RO for system, and upgrade is just switch ISO.
>>
>> For real hardware, it can be done with such approach - make two
>> partitions with fixed size, and when you need upgrade - just `dd` new image
>> to other partition, mark it as [bootonce] (And if all is ok, as [bootme]),
>> reboot = and you have new OS very quick, with same configs (except for some
>> LARGE changes which could happen in /etc and touch your configs), and with
>> same packages.
>>
>> BTW, when you mount /etc-rw union over /etc, when you'll need upgrade,
>> mergemaster could take less time, less places for errors - since you had to
>> merge only changed files(which present on /etc-rw).
>> I think these days with current hw, no one will complain against lost 1Gb
>> to achieve clean and simple OS upgrade.
>>
>> I'm not saying about possible way to shrink it further (no debug, gzip,
>> etc) - get lesser partition, but still RO, and get ability to make
>> something dd if=/dev/gpt/rootfs bs=1M | sha256
>>
>>
>> --
>> Regards,
>> Alexander Yerenkow
>>
>
>
>
> I am assuming that ANY SOFTWARE read-only protection , whatever it is ,
> has security vulnerability .
> Therefore , the first approach should be to provide HARDWARE read only .
> If this is supplied , the next necessity is that , programs in
> write-protected part should not attempt to write anything onto
> write-protected part .
>

If you consider writing as a security issue, you better should look at
cd-r, and also for hash checking with public-private keys pair (you prepare
image, put there public key, calc hash, sign hash with your private key,
and make some script to check hash during boot, and probably over time).

And don't be over-concerned about security, it's danger one-way road.



>
>
>
> Thank you very much .
>
> Mehmet Erol Sanliturk
>
>
>
>
>
>


-- 
Regards,
Alexander Yerenkow