# New FreeBSD derivative... imgBSD



## ashleyd (Oct 27, 2013)

Hi all,

I have worked for over two years on what I believe could be my perfect OS. It is in the very early stages and have only just made an initial release today. The simplest way to describe it is a cross between FreeNAS and PC-BSD (but with GNOME instead of KDE). It's a 64-bit desktop version of FreeBSD 9.1 contained in an image.

The website for the project is http://www.imgbsd.org.

There is a Virtualbox image to download and try and all source is held in git: https://github.com/imgBSD/imgBSD.

I have been using this forum for years and so would appreciate feedback from any of you here.


----------



## throAU (Oct 28, 2013)

One comment:  Just because programs are embedded into the operating system, it doesn't mean they never need to be updated.  If they are vulnerable to exploit while in RAM, they can still be used to steal data.


----------



## kpa (Oct 28, 2013)

You could explain why this work needs to be new derivative of FreeBSD instead of contributing your work to FreeBSD itself. Unless you can provide some explanation for the motivation for this project many people will dismiss it as yet another not so welcome fork of FreeBSD.


----------



## jb_fvwm2 (Oct 28, 2013)

*Impressed.*

I've not done much more than read at the new URL a few minutes; but having used ghostbsd.org, freesbie, etc, it seems to be very impressive and inviting to those wishing to try FreeBSD.  Surely, if I had more time  (etc), I'd be emailing others of that link... [I, for example, now understand much more how one would run FreeBSD within windows before a full install...  ]


----------



## ashleyd (Oct 28, 2013)

throAU said:
			
		

> One comment:  Just because programs are embedded into the operating system, it doesn't mean they never need to be updated.  If they are vulnerable to exploit while in RAM, they can still be used to steal data.



Hi @throAU,

I will have to go back and reword this. Agreed. However, when the image is updated it will also contain new versions of applications that have been updated in ports, therefore feature changes and security fixes for those applications will be included in the updated image.

This of course raises the question of how frequently updated images would need to be rolled out, and would obviously make it not suitable for environment where security flaws would require patching immediately such as with servers. However this is no different to issues faced by NanoBSD and FreeNAS currently.

My intention is that new images would be made available regularly anywhere up to weekly. Using images deltas for releases would mean only a few megabytes would have to be downloaded for each new image.


----------



## ashleyd (Oct 28, 2013)

kpa said:
			
		

> You could explain why this work needs to be new derivative of FreeBSD instead of contributing your work to FreeBSD itself. Unless you can provide some explanation for the motivation for this project many people will dismiss it as yet another not so welcome fork of FreeBSD.



Hi @kpa. I see your point and this hadn't occurred to me so I will have to add something regarding this to the website.

For anyone reading this post:

It was never my intention to "fork" FreeBSD or create "just another distro" (after all we don't want to end up like Linux!) as it's another way to use the unmodified FreeBSD source code (excluding the odd patch). In the same way NanoBSD is just a different way to use the 100% FreeBSD codebase.

In terms of just another "BSD", this project (if continued) will not dilute resources away from any of the existing BSDs as I do not have the time or skills to fork the codebase, charisma to steal away FreeBSD developers or even the need! Therefore it is, just an attempt at making FreeBSD more accessible, in the same way that time and resources have been put into ARM support, which I see as strengthening FreeBSD by providing alternative ways to access the same resources, not diluting it by spreading resources across different architecture.

In a less relevant way, this project was started the other-way round to forking FreeBSD, with an end goal and FreeBSD as a means of getting there. I wanted to create an alternative Operating System that addressed some of the flaws I believed users where faced with on a daily bases using the then current OS's, and I happened to base it on FreeBSD, a dependable, predictable development platform that I have always found a joy to use.


----------



## Martillo1 (Oct 28, 2013)

I am going to give it a try in qemu under OpenBSD. Downloading...


----------



## ChalkBored (Oct 28, 2013)

You've got a typo in the last paragraph on your page.
"read/wright NTFS support"

It's the wrong version of write, so a spellchecker would have missed it.


----------



## vanessa (Oct 28, 2013)

I'll also try it as soon as I get my damn VirtualBox back on track ...


----------



## throAU (Oct 29, 2013)

ashleyd said:
			
		

> This of course raises the question of how frequently updated images would need to be rolled out, and would obviously make it not suitable for environment where security flaws would require patching immediately such as with servers. However this is no different to issues faced by NanoBSD and FreeNAS currently.



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.

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.

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.

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...


----------



## ashleyd (Oct 29, 2013)

Martillo1 said:
			
		

> I am going to give it a try in qemu under OpenBSD. Downloading...



Good to hear it, please let me know how you get on using qemu. I have mentioned just Virtual Box purely due to lack of time. I am aware there are alternatives . I also wanted to get the process as smooth as possible with one alternative.

When I get time I will look into the options and extend instructions.


----------



## ashleyd (Oct 29, 2013)

ChalkBored said:
			
		

> You've got a typo in the last paragraph on your page.
> "read/wright NTFS support"
> 
> It's the wrong version of write, so a spellchecker would have missed it.



Thanks for letting me know. Last night I went through it all again. However, you only get 10 points as you didn't notice all the other mistakes :e. My excuses are: I'm dyslexic, my girlfriend has been away for a week and also I should have known better than to try and proof read it myself. I was going to reply and say at least I didn't write curtain instead of certain (my usual offender), and blow me down my girlfriend found that last night in the wiki!


----------



## ashleyd (Oct 29, 2013)

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.


----------



## ashleyd (Nov 8, 2013)

I have just released a second image. http://www.imgbsd.org/releases.htm

The main improvement is that I have upgraded the base system to FreeBSD 9.2. It took longer than expected due to compilation issues with higher parallel make options and trying to investigate this. That took most of my time available, future releases will have more functional changes.

If anyone is interested in trying it can I suggest you first download the intial image (based on FreeBSD 9.1), and then upgrade to this new one to see just how simple upgrading the entire OS and all bundled ports is!

With virtual box you could:
1. First download this initial compressed Vbox image
2. Follow these virtual box instructions starting at "Setting up the Virtual Machine" here
3. Follow the first section "Adding a new user" from the getting started guide
4. Login as your user and run the following two commands:

```
wget http://s3.imgbsd.org/files/images/imgBSD_GENERIC_b9.2-1.0_20131107.img.xz
sudo img_update local imgBSD_GENERIC_b9.2-1.0_20131107.img.xz
```

If you already have Virtual Box (and ignoring download time) you could try all 4 steps in less than 30 minutes !


----------



## Martillo1 (Nov 8, 2013)

ashleyd said:
			
		

> Good to hear it, please let me know how you get on using qemu. I have mentioned just Virtual Box purely due to lack of time. I am aware there are alternatives . I also wanted to get the process as smooth as possible with one alternative.
> 
> When I get time I will look into the options and extend instructions.



I am sorry, but after recent upgrade to 5.4, OpenBSD and Nvidia graphics cards do not get along well , so *I* had to give it up. Now I am on FreeBSD again. Let's see what can I do about testing your derivative


----------



## markbsd (Nov 12, 2013)

This is really great! Thanks, @ashleyd. You're an asset to the community.


----------



## markbsd (Nov 12, 2013)

Typo:



> all bundled together into a single package*s*





> consider sharing it with imgBSD.*\* For instance,


----------



## markbsd (Nov 12, 2013)

Maybe a "secure" image, one without Google Chrome and already configured with the Tor Browser Bundle, Squid and Privoxy, and perhaps even Open-, or Fluxbox instead of GNOME. So it really would be a lightweight and secure portable OS. That would surely be highly prized.


----------



## ashleyd (Nov 16, 2013)

markbsd said:
			
		

> Maybe a "secure" image, one without Google Chrome and already configured with the Tor Browser Bundle, Squid and Privoxy, and perhaps even Open-, or Fluxbox instead of GNOME. So it really would be a lightweight and secure portable OS. That would surely be highly prized.



Thanks @markbsd! I have corrected the mistakes you found.

Great suggestion, I'll make a start. However, I'm not sure if replacing GNOME2 with something lighter would make much of a difference to the overall size. Since I'am only installing the minimum amount of gnome components, if any of the additional ports used gconf or gtk (which they almost certainly would), many of the current dependencies will be pulled in anyway, plus you will most likely have QT dependencies. Replacing Nautilus and GDM with lighter alternatives would probably make a bigger difference.

In addition, it would be helpful to have as many people helping improve/test a single Desktop Environment to make sure it works as well as possible.

I have made the basic changes necessary to create a Raspberry Pi image (need to get a second Pi to try what I've done), this would probably also benefit from a more stripped down image as you suggested, so perhaps I could combine effort moving away from gnome (this is of course if Xorg works on Pi on FreeBSD).

Perhaps you could suggest an initial list of ports from the ports tree that should be bundled with the a security orientated image .


----------



## markbsd (Nov 18, 2013)

You're likely right -- I don't know enough to say otherwise -- about a GNOME alternative. I think, yes, keep it as GNOME, especially considering you're already just installing the minimum. Perhaps, as you say, an alternative to GDM and Nautilus would be prudent?

Again, I wouldn't know too much about what ports to include except for: Tor; Vidalia; Privoxy; Squid; and TorSocks. There would no doubt be others, maybe some of the security experts here could offer some input. Alternatively, the Tor mailing list has some really knowledgeable people -- and they enjoy helping and offering advice.

The Pi image sounds really good! That will be sought after too. I really think a security focused image will be good. Something to replace Liberte with a better base OS


----------



## ashleyd (Dec 26, 2013)

Hi, 

For anyone who is interested:

1. I have made changes to the website to hopefully make the intent of the project clearer.
2. I have made a new release with new features (nothing big), details can be found here http://imgbsd.org/releases.htm.

I have been unable to work on the suggestions in this thread as I have not had much time and have spent most of it working on trying to get partial image updating working. When I'm finished, if you already have an image you will only need to download deltas (of around 10MB) and not a whole image of 350MB. The new image is generated from the old image and the deltas.
This will probably take me a few more weeks (I will have to write a lot of tests!) but I think will make make a huge difference to the project.


----------

