SecBSD is inclusive. We want SecBSD to be a space where people of all
backgrounds can collaborate to create the best offensive toolkit known
to mankind, crafted by a strong and florishing community. Our core
values extend beyond just the development, but encompass SecBSD
as a whole.
Diversity is a huge strength and is critical to the long term success of SecBSD. To that end we have a few ground rules that we ask people to adhere to. This code applies equally to everyone representing the SecBSD project. in any way, from new members, to committers, to the core team itself. These rules are intended to ensure a safe, harassment-free environment for all and to ensure that everyone feels welcome both working within, and interacting with, the project.
This document is not an exhaustive list of things that you should not do. Rather, consider it a guide to make it easier to enrich all of us and the technical communities in which we participate. This code of conduct applies to all spaces used by the SecBSD project; online and offline.
Respect the opinion, attitude, background, preferences, traits and human aspects of others.
Do not discriminate others, based on any and all aspects - whether negative or positive.
SecBSD is about collaborating, the community and creating a toolkit. The project is not - in any way - a platform to harass others, including but not limited to unwanted attention, intimidation, stalking, trolling, sexual attention, etc.
Try to substantiate shared information and opinions rather than stating your opinion as-if it were a fact.
SecBSD will base releases upon the -stable branch of OpenBSD.
If you are contributing code o ports devel runs on -current.
A code editor of your liking (ed, vi, vim, emacs, etc)
A machine running SecBSD.
1. Install some dependencies
$ doas pkg_add git gnupg
GPG is used to signing commits, which is strongly preferred though not required (as of now).
2. (Optional) clone the repository that best fits your idea.
3. Either start with working out your idea (ports, code, docs) or message Purple Rain or h3artbl33d about to-do's
4. Submit your work through a pull request or by contacting a core member. We do require at least one core member signing off commits.
We respect your privacy. It is up to you whether you want to disclose
any personal details. If you want to be solely known by your nickname,
you might want to create an identity dedicated to the SecBSD project
(nickname, emailaddress and GPG key). Be sure to route your traffic
over a pseudo-anonymous VPN network or via Tor.
While we require a core member signing your contributions, you and only you are responsible and remain responsible for your contributions. Eg, if you are contributing a port: keep it up to date with upstream. If not kept up-to-date, we might consider the port to be obsolete and eventually remove it.
Currently, we do not have an established means of communication, like IRC/XMPP or a forum. As soon as anything is setup, we'll update this document accordingly.
The SecBSD installer uses a special ramdisk kernel (bsd.rd) that spawns a live environment running entirely in memory. It contains the install script and a small number of utilities needed to perform a complete installation. These utilities can also be useful for disaster recovery.
The ramdisk kernel can be booted from a number of different sources:
An existing partition
Over the network
(PXE or other network boot options)
Not every platform supports all of these options.
If you have a running SecBSD system, bsd.rd is all you need to
reinstall or upgrade to a newer version.
To do so,
download and verify the new
place it on an existing filesystem, and boot from it.
The general method of booting bsd.rd is to change your boot kernel
from /bsd to /bsd.rd through whatever means used on
Booting from bsd.rd on an amd64 system can be done like so:
Using drive 0, partition 3. Loading...... probing: pc0 com0 com1 mem[638K 1918M a20=on] disk: hd0+ hd1+ >> SecBSD/amd64 BOOT 3.33 boot> bsd.rd
This will boot the kernel named bsd.rd from the first partition
of the first recognized hard disk.
If you need to specify a different drive or partition, just prefix the kernel name with its location. The following example would boot from the fourth partition of the second hard drive:
Using drive 0, partition 3. Loading...... probing: pc0 com0 com1 mem[638K 1918M a20=on] disk: hd0+ hd1+ >> SecBSD/amd64 BOOT 3.33 boot> boot hd1d:/bsd.rd
SecBSD boot loaders are documented in the architecture-specific boot(8) man pages.
Before you start, you should have some idea what you want to end up with. A few things worth considering beforehand:
Hardware installed and available:
Verify compatibility with your hardware. You may want to consult the platform-specific installation notes, especially if you're using one of the non-x86 CPU architectures. They contain detailed instructions and any possible caveats:
If wireless internet is your only option, does your card require additional firmware? If so, you'll need to manually download it to a USB drive or similar device, then use the fw_update(1) tool to enable it after SecBSD is installed.
Install method to be used
Desired disk layout:
Network settings, if not using DHCP:
The following installation images are available:
An SHA256 file containing checksums can be found in the same directory as the installation files. You can confirm that none of the downloaded files were mangled in transit using the sha256(1) command.
$ sha256 -C SHA256 miniroot*.img (SHA256) minirootXX.img: OK
Or, if you're using an OS with the GNU coreutils:
$ sha256sum -c --ignore-missing SHA256 minirootXX.img: OK
However, this only checks for accidental corruption. You can use signify(1) and the SHA256.sig file to cryptographically verify the downloaded image.
$ signify -Cp /etc/signify/secbsd-XX-base.pub -x SHA256.sig miniroot*.img Signature Verified minirootXX.img: OK
Note that the signify package on other operating systems may not include the required public key, or it may be installed in another location.
The installXX.iso and installXX.img images do not
SHA256.sig file, so the installer will complain that
it can't check the signature of the included sets:
Directory does not contain SHA256.sig. Continue without verification? [no]
This is because it would make no sense for the installer to verify them.
If someone were to make a rogue installation image, they could certainly
change the installer to say the files were legitimate.
If the image's signature has been verified beforehand, it is safe to answer "yes" at that prompt.
A bootable USB flash drive can be created by attaching the target device and copying over the image with dd(1).
Using SecBSD, assuming the device was recognized as sd6:
# dd if=install*.img of=/dev/rsd6c bs=1m
Note that the raw I/O device is used, rsd6c rather than sd6c.
Details of this will vary on other platforms. The GNU version of dd will require bs=1M (note the capital M) instead. If you're using a different OS, be sure to select the appropriate device name: /dev/sdX on Linux or /dev/rdiskX on macOS for example.
You can create a bootable CD-ROM on SecBSD by using cdio(1).
# cdio tao cd*.iso
The installer is designed to install SecBSD in a very usable default
configuration with a minimum of user intervention.
In fact, you can often just hit
<Enter> to get
a good SecBSD install, moving your hands to the rest of the keyboard
only to enter the root password.
After the dmesg(8) is shown, you will see the first installer question:
... root on rd0a swap on rd0b dump on rd0b erase ^?, werase ^W, kill ^U, intr ^C, status ^T Welcome to the SecBSD/amd64 X.X installation program. (I)nstall, (U)pgrade, (A)utoinstall or (S)hell?
(I)nstall and follow the instructions.
Some libraries from
xbaseXX.tgz, like freetype or fontconfig, can
be used outside of X by programs that manipulate text or graphics.
Such programs will usually need fonts, either from
For the sake of simplicity, the developers decided against maintaining a minimal
xbaseXX.tgz set that would allow most non-X ports to run.
Much like RAID, full disk encryption in SecBSD is handled by the softraid(4) subsystem and bioctl(8) command. This section covers installing SecBSD to a single encrypted disk, and is a very similar process to the previous one. Note that "stacking" softraid modes (mirrored drives and encryption, for example) is not supported at this time.
Select (S)hell at the initial prompt.
Welcome to the SecBSD/amd64 X.X installation program. (I)nstall, (U)pgrade, (A)utoinstall or (S)hell? sFrom here, you'll be given a shell within the live environment to manipulate the disks. For this example, we will install to the
sd0SATA drive, erasing all of its previous contents.
Since the installer does not have many device nodes by default, make
/dev/sd0 device exists:
# cd /dev && sh MAKEDEV sd0You may want to write random data to the drive first with something like the following:
# dd if=/dev/urandom of=/dev/rsd0c bs=1mThis can be a very time-consuming process, depending on the speed of your CPU and disk, as well as the size of the disk. If you don't write random data to the whole device, it may be possible for an adversary to deduce how much space is actually being used.
If you're booting from MBR, do:
# fdisk -iy sd0If you use GPT for UEFI booting, do:
# fdisk -iy -g -b 960 sd0Next, create the partition layout:
# disklabel -E sd0 Label editor (enter '?' for help at any prompt) sd0> a a offset:  size:  * FS type: [4.2BSD] RAID sd0*> w sd0> q No label changes.We'll use the entire disk, but note that the encrypted device can be split up into multiple partitions as if it were a regular hard drive.
Now we can build the encrypted device on our "a" partition.
# bioctl -c C -l sd0a softraid0 New passphrase: Re-type passphrase: sd1 at scsibus2 targ 1 lun 0: <SECBSD, SR CRYPTO, 005> SCSI2 0/direct fixed sd1: 19445MB, 512 bytes/sector, 39824607 sectors softraid0: CRYPTO volume attached as sd1Instead of a passphrase, you may want to use a keydisk.
Make sure the
/dev/sd1 device is accounted for:
# cd /dev && sh MAKEDEV sd1All data written to
sd1will now be encrypted with AES in XTS mode.
As in the previous example, we'll overwrite the first megabyte of our new pseudo-device.
# dd if=/dev/zero of=/dev/rsd1c bs=1m count=1Type
exitto return to the main installer, then choose this new device as the one for your installation.
[...] Available disks are: sd0 sd1. Which disk is the root disk? ('?' for details) [sd0] sd1You will be prompted for the passphrase on startup, but all other operations should be handled transparently.
As an alternative to using a passphrase, it's possible to use a key stored on a separate device (e.g. a USB stick) to unlock your encrypted disk.
Initialize your keydisk with
fdisk(8), then use
to create a 1 MB RAID partition for the key data.
If your keydisk is
sd1 and the drive you want to encrypt is
sd0, the output will look something like this:
# bioctl -c C -k sd1a -l sd0a softraid0 sd2 at scsibus3 targ 1 lun 0: <SECBSD, SR CRYPTO, 005> SCSI2 0/direct fixed sd2: 19445MB, 512 bytes/sector, 39824607 sectors softraid0: CRYPTO volume attached as sd2You won't be prompted to enter a passphrase because you used a keydisk instead. The keydisk must be inserted at startup time.
You can backup and restore your keydisk using dd(1):
# dd bs=8192 skip=1 if=/dev/rsd1a of=backup-keydisk.img # dd bs=8192 seek=1 if=backup-keydisk.img of=/dev/rsd1a
When a critical bug is found, the fix will be committed to the -current tree
(and made available in snapshot builds)
as soon as possible.
From that point on, things are handled differently depending on whether the
problem was in the SecBSD base system or a third party package.
This section details how to keep your system up to date between releases.
For the SecBSD base system, security fixes are normally applied to the two most recent releases. There are four options:
-uflag to get the new files.
/usr/ports/infrastructure/bin/pkg_outdatedscript to list any packages in need of rebuilding, and issue
make updatein the affected port directory. In some cases, existing ports will need to be uninstalled before rebuilding. To be alerted of port updates, consider following the ports-changes mailing list.
The doas(1) tool lets a system administrator permit certain users to run specific commands as another user. Regular users can run administrative commands, only being required to authenticate as themselves, without the need for the root password.
For example, if appropriately configured, the following command would display root's crontab(5) file:
$ doas -u root crontab -lCommands invoked by doas(1) are logged to
/var/log/secureby default. Check the doas.conf(5) manual for configuration examples.
There are many applications one might want to use on an SecBSD system. To make this software easier to install and manage, it is ported to SecBSD and packaged. The aim of the package system is to keep track of which software gets installed, so that it may be easily updated or removed. In minutes, a large number of packages can be fetched and installed, with everything put in the right place.
The ports collection does not go through the same thorough security audit that is performed on the SecBSD base system. Although we strive to keep the quality of the packages high, we just do not have enough resources to ensure the same level of robustness and security.
The SecBSD ports team considers packages to be the goal of their porting work, not the ports themselves. In general, you are advised to use packages over building an application from ports.
Packages can be easily managed with the help of several utilities:
In order to run properly, application X may require that other applications
Y and Z be installed.
Application X is said to be dependent on these other applications, which is
why Y and Z are called dependencies of X.
In turn, Y may require other applications P and Q, and Z may require
application R to function properly.
This way, a whole dependency tree is formed.
Packages look like simple .tgz bundles. Basically they are just that, but there is one crucial difference: they contain some extra packing information. This information is used by pkg_add(1) for several purposes:
/var/db/pkgby default. This will, among other things, prevent the dependencies of a package from being deleted before the package itself has been deleted. This helps ensure that an application cannot be accidentally broken by a careless user.
The pkg_add(1) utility is used to install packages. If multiple flavors of a package exist, you will be prompted to choose which one you want to install.
# pkg_add rsync Ambiguous: choose package for rsync a 0: <None> 1: rsync-3.1.2p0 2: rsync-3.1.2p0-iconv Your choice:
Here you would select 1 if you want the standard package or 2
if you need iconv support.
You can also choose the flavor directly on the command line by using
pkg_add rsync-- (for the default) or
pkg_add rsync--iconv (for the iconv flavor).
It is possible to specify multiple package names on one line, which then all get installed at once, along with their dependencies. You may also specify the absolute location of a package, be it a local file or remote URL. Supported URL prefixes are http, https, ftp and scp.
For some packages, important additional information will be given about the configuration or use of the application.
# pkg_add jove jove-220.127.116.11p0: ok --- +jove-18.104.22.168p0 ------------------- See /usr/local/share/jove/README about changes to /etc/rc or /etc/rc.local so that the system recovers jove files on reboot after a system crashAdditionally, some packages provide configuration and other information in a file located in
For your safety, if you are installing a package which you had installed earlier and removed, configuration files which have been modified will not be overwritten. The same is true for when you upgrade a package.
Sometimes you may encounter an error like the one in the following example:
# pkg_add xv quirks-2.367 signed on 2017-10-03T11:21:28Z xv-3.10ap4:jpeg-6bp3: ok xv-3.10ap4:png-1.2.14p0: ok xv-3.10ap4:tiff-3.8.2p0: ok Can't install xv-3.10ap15 because of libraries |library X11.16.1 not found | not found anywhere Direct dependencies for xv-3.10ap15 resolve to png-1.6.31 jasper-1.900.1p5 tiff-4.0.8p1 jpeg-1.5.1p0v0 Full dependency tree is png-1.6.31 tiff-4.0.8p1 jasper-1.900.1p5 jpeg-1.5.1p0v0
The packing information bundled in the package includes information about shared libraries that the package expects to be installed. If one of the required libraries can't be found, the package is not installed because it would not function anyway.
There are several things to check:
Let's say you had an older version of unzip installed before upgrading this box to the latest SecBSD release. You can easily upgrade the package to the newer version like this:
# pkg_add -u unzip unzip-5.52->unzip-5.52p0: ok Read shared items: ok
When a package has dependencies, they are also examined for updates.
Invoking pkg_add(1) with
-u flag will try to update all installed packages.
This is highly recommended over updating individual packages on their own.
To remove a package, simply take the name of the package and use pkg_delete(1).
# pkg_delete screen screen-4.0.3p6: ok Read shared items: okAgain, modified configuration files will not be removed. Unneeded dependencies can be trimmed by running
pkg_delete -aat any time.
Network configuration in SecBSD is done with text files in
Typically, these settings are initially configured during the
fxp0 at pci0 dev 10 function 0 "Intel 82557" rev 0x0c: irq 5, address 00:02:b3:2b:10:f7 inphy0 at fxp0 phy 1: i82555 10/100 media interface, rev. 4This device uses the fxp(4) driver and is assigned the number 0 here.
You can find out what network interfaces have been identified by using the ifconfig(8) utility. The following command will show all network interfaces on a system.
$ ifconfig lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33200 index 3 priority 0 llprio 3 groups: lo inet 127.0.0.1 netmask 0xff000000 fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 lladdr 00:02:b3:2b:10:f7 index 1 priority 0 llprio 3 media: Ethernet autoselect (100baseTX full-duplex) status: active inet 10.0.0.38 netmask 0xffffff00 broadcast 10.0.0.255 enc0: flags=0<> index 2 priority 0 llprio 3 groups: enc status: active pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33200 index 4 priority 0 llprio 3 groups: pflogThis sample shows only one physical Ethernet interface:
fxp0. An IP is configured on it, hence the values
inet 10.0.0.38 netmask 0xffffff00 broadcast 10.0.0.255. The
RUNNINGflags are also set on it.
The netstart(8) script configures
network interfaces at boot time using
hostname.if(5) files, where
"if" is replaced by the full name of each interface.
The example above would use the file
the following options:
inet 10.0.0.38 255.255.255.0This
hostname.fxp0file also has an interactive equivalent:
# ifconfig fxp0 10.0.0.38 255.255.255.0Finally, you will notice several other interfaces come enabled by default. These are virtual interfaces that serve various functions. The following manual pages describe them:
The following cards support Host-based Access Point (HostAP) mode, permitting them to be used as a wireless access point:
media subcommand shows media capabilities of network interfaces.
For wireless devices, it displays supported 802.11a/b/g/n media modes and the
supported operating modes (
For example, to see media capabilities of interface
$ ifconfig ath0 mediaIn order to use some wireless cards, you will need to acquire firmware files with fw_update(1). Some manufacturers refuse to allow free distribution of their firmware, so it can't be included with SecBSD.
Another option to consider: use a conventional NIC and an external bridging wireless access point for your SecBSD-based firewall. This has the added advantage of letting you easily position the antenna where it is most effective, which is often not directly on the back of your firewall.
Adapters based on supported chips can be used like any other network interface. To connect an SecBSD system to an existing wireless network, use the ifconfig(8) utility.
An example of a hostname.if(5) file for a wireless client might be:
nwid puffyuberalles wpakey passwordhere dhcpOr, for multiple access points:
join home-net wpakey passwordhere join work-net wpakey passwordhere join cafe-wifi dhcp
Note that the
dhcp keyword should be after the other configuration
lines, as the network adapter will not be able to send a DHCP request until
it is configured.
Trunks are virtual interfaces consisting of one or more network interfaces. In this section, our example will be a laptop with a wired bge0 interface and a wireless iwn0 interface. We will build a trunk(4) interface using both of them.
To do this, we first activate the two physical ports, then assign them to
# echo up > /etc/hostname.bge0The wireless interface, however, needs a bit more configuration. It will need to attach to our wireless WPA-protected network:
$ cat /etc/hostname.iwn0 nwid puffynet wpakey mysecretkey upNow, our trunk interface is defined like this:
$ cat /etc/hostname.trunk0 trunkproto failover trunkport bge0 trunkport iwn0 dhcpThe trunk is set up in
failovermode, so either interface can be used. If both are available, it will prefer the
bge0port, since that is the first one added to the trunk device.