throAU said:
Actually, I'd suggest that desktop images are a lot more critical to secure than servers, because of the massively increased amount of software that is exposed to potentially malicious input. Well, at least as far as preventing an exploit goes - the consequences are potentially less severe though. Also, command line software (on servers), being a lot simpler is a lot easier to audit and tends to be less prone to bugs than GUI desktop software.
True, and thats why images updates will have to happen frequently. My intention was to make the process easy and flexible to make alternative image releases, much like Linux distros have GNOME, KDE, Xfce variants. There could be a security variant that has images with security fixes sent even more frequently, and perhaps with ports chosen specifically for a more secure environment.
And of course due to the beauty of imgBSD you could wake up one day, decide you need more security in your life and swap to the security orientated image in 5 minutes.
throAU said:
Typically, FreeNAS (for example) will not be sitting out on the internet or retrieving data from the internet. Even for servers that I have facing the internet, they are typically exposing only one service, further reducing the threat surface.
Agreed, and there's no reason why you can't have a nice blacklisting firewall by default in the OS. I was planning on doing this. Would only take a few minutes to implement such a feature.
throAU said:
If I understand correctly, this is intended to be a secure run from USB stick desktop platform? If so, then you're going to have issues when an exploit in an individual package is found. Unlike FreeNAS, you have a desktop user who is going to be pointing your potentially insecure applications at internet sourced data.
Not quite. It happily runs from USB, or SATA, as it makes no assumption of where it is run from or installed to. For instance I have it installed on my laptop's SSD and use it daily, dual booting with Linux. When I want to try a new image, I use the script to write it to a USB, then boot from that. By a happy coincidence (that I have not got to the bottom of yet) even though it's booted and is running from USB, my configuration partition (
/cfg) and user partition (
/home) is mounted from the internal drive. Meaning I can try the new OS but with my normal user account and files!
I don't believe this is any less secure than current alternatives. Granted, currently you can't patch applications yourself, but how many FreeBSD users patch their own source and recompile the application the second a vulnerability is found? How many users go several days, weeks or months before updating? There is always a delay, the question is how long is acceptable.
With an image you get all the latest ports built from scratch, latest security fixes to the FreeBSD source, plus new features and fixes, all guaranteed to be compatible with each other, every time you upgrade. If you regularly update the image you will never have to worry about exploits, updates or patching ever again
.
throAU said:
Unless there's a way to update individual applications within the image, it means that updates are a matter of retrieving an entire new image, even if the only change required is a couple of kilobytes in one application. I'm not sure that's a win for an interactive desktop platform.
Maybe patches won't be so bad though? If all your installs are the same then patching is a simple diff between version X and version Y...
Absolutely, I agree, you don't want to be downloading a 300MB+ file for every release, especially if you don't have a fast connection. Regarding your suggestion for patching, yes it's possible, and the spare OS is sitting there ready to be mounted and patched. However, I believe there is a huge benefit in dealing with images only and not making alterations at any point; even patches. That image has been verified, tested and confirmed working before it gets to you, perhaps even signed. Either way a reboot will be required to activate the changes. Unless... union mounts where done to the patched spare OS (mounting over the top of the current one), that way you will use the new code instantly on next execution of the application... I wonder.
As mentioned in the FAQ
http://wiki.imgbsd.org/index.php/F.A.Q#Can_I_update_the_OS.3F regarding updating. I already have a script that produces a delta between two images.
This way you only need one complete image stored on your system at any point and can recreate the newer images. This will effectively get you to the exact same point as someone downloading the entire image, but for just a few MB's per delta. I have not implemented it yet as I am unsure about eventual naming conventions and the fact that there will need to be some source of meta-data for clients to know which delta to apply to which image... for all the deltas since the first image. I guess there could always be a default fall-back to simply download the entire latest image if this process failed at any point, this would make the process more resilient, especially if naming conventions changed.
, so I had to give it up. Now I am on FreeBSD again. Let's see what can I do about testing your derivative