SecBSD is inclusive. We want SecBSD to be a space where people of all
backgrounds can collaborate to create the best OS for hackers 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 developing
a unix operating system, hacking and share.
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.
Contribute your expertise and hacking skills by using the
-current branch of
SecBSD.
Whether you contribute to the code base or port development,
make sure to use -current.
1. A computer running the last snapshot of SecBSD:
amd64
| arm64
2. A code editor of your liking (ed, vi, vim, emacs, nano, etc)
3. If an port does not exist for SecBSD. The first thing to do
is ask to Purple Rain
or h3artbl33d
if anyone is working on the port -- there may be one in progress.
If no such port exists, then you may be the maintainer.
4. (Optional) clone the repository that best fits your idea.
You might want to look at the FreeBSD ports
or NetBSD pkgsrc
for inspiration.
5. Submit your work 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:
CD/DVD
USB drive
An existing partition
Over the network
(PXE or other
network boot options)
Floppy disk
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 bsd.rd,
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
your platform.
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:
Machine name.
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-14-base.pub -x SHA256.sig install14.img Signature Verified install14.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
contain an 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 sd1:
# dd if=install14.img of=/dev/rsd1c bs=1m
Note that the raw I/O device is used, rsd1c rather than sd1c.
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?
Choose (I)nstall and follow the instructions.
bsd
bsd.mp
bsd.rd
baseXX.tgz
compXX.tgz
manXX.tgz
gameXX.tgz
xbaseXX.tgz
xshareXX.tgz)
xfontXX.tgz
xservXX.tgz
xshareXX.tgz
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 xfontXX.tgz or
font packages.
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 1.3 installation program. (I)nstall, (U)pgrade, (A)utoinstall or (S)hell? s
From here, you'll be given a shell within the live environment to manipulate
the disks.
For this example, we will install to the sd0 SATA drive, erasing
all of its previous contents.
Since the installer does not have many device nodes by default, make
sure the /dev/sd0 device exists:
# cd /dev && sh MAKEDEV sd0
You 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.
Next, initialize the disk with fdisk(8) and create the softraid partition with disklabel(8).
If you're booting from MBR, do:
# fdisk -iy sd0
If you use GPT for UEFI booting, do:
# fdisk -iy -g -b 960 sd0
Next, create the partition layout:
# disklabel -E sd0 Label editor (enter '?' for help at any prompt) sd0> a a offset: [64] size: [39825135] * 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 sd1
Instead of a passphrase, you may want to
use a keydisk.
Make sure the /dev/sd1 device is accounted for:
# cd /dev && sh MAKEDEV sd1
All data written to sd1 will 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=1
Type exit to 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] sd1
You 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
disklabel(8)
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 sd2
You 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:
If you're running a supported release of SecBSD, you can simply use the syspatch(8) utility to upgrade any files in need of security or reliability fixes. This is the quickest and easiest method to get the base system up to date. Security advisories are sent to the announce mailing list.
Fetch (or update) your source tree with CVS or Git, then recompile the kernel and userland.
While applying fixes from the errata page typically requires less time than a CVS checkout/update and rebuild, there is no universal set of instructions to follow. Sometimes you must patch and recompile one application, sometimes more.
As all fixes are applied to the -current code base, updating your system to the latest snapshot is a good way to get all the fixes at once. However, running -current is not for everyone.
For third party software installed via packages, fixes are normally only applied to the most recent release. There are three options:
Binary packages for -stable are rebuilt only for security issues or other
major fixes.
Simply call pkg_add(1) with
the -u flag to get the new files.
Fetch (or update) your ports tree,
run the /usr/ports/infrastructure/bin/pkg_outdated script to
list any packages in need of rebuilding, and issue make update
in 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.
Binary packages for -current are rebuilt on a regular basis, and these new packages will include any security fixes.
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 -l
Commands invoked by doas(1)
are logged to /var/log/secure by 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/pkg by 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-4.16.0.73p0: ok --- +jove-4.16.0.73p0 ------------------- 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
/usr/local/share/doc/pkg-readmes.
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
only the -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 -a
at any time.
Network configuration in SecBSD is done with text files in /etc.
Typically, these settings are initially configured during the
installation process.
Interfaces are named by the type of card, not the type of connection. For example, here's a dmesg(8) snippet for an Intel Fast Ethernet network card:
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. 4
This 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: pflog
This 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 UP and RUNNING flags 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 /etc/hostname.fxp0, containing
the following options:
inet 10.0.0.38 255.255.255.0
This hostname.fxp0 file also has an interactive equivalent:
# ifconfig fxp0 10.0.0.38 255.255.255.0
Finally, you will notice several other interfaces come enabled by default. These are virtual interfaces that serve various functions. The following manual pages describe them:
Other virtual interfaces can be added with
ifconfig(8)'s create
subcommand.
SecBSD has support for a number of wireless chipsets. Further supported devices can be found in usb(4) and pci(4). The precise extent of their support is described in the driver man pages.
The following cards support Host-based Access Point (HostAP) mode, permitting them to be used as a wireless access point:
The ifconfig(8)
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 (hostap, ibss,
monitor).
For example, to see media capabilities of interface ath0, type:
$ ifconfig ath0 media
In 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 dhcp
Or, 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
trunk0.
# echo up > /etc/hostname.bge0
The 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 up
Now, our trunk interface is defined like this:
$ cat /etc/hostname.trunk0 trunkproto failover trunkport bge0 trunkport iwn0 dhcpThe trunk is set up in
failover mode,
so either interface can be used.
If both are available, it will prefer the bge0 port,
since that is the first one added to the trunk device.
Login as root and create doas.conf file.
# echo "permit keepenv :wheel" > /etc/doas.conf
Logout and then login as a user.
$ doas pkg_add -v xfce xfce-extras consolekit2 $ vi ~/.xsession and uncomment the line 14 exec /usr/local/bin/startxfce4 --with-ck-launch $ save and quit :wq!
$ doas rcctl enable messagebus xenodm $ doas rcctl start messagebus xenodm $ doas reboot
It is recommended to run X with the xenodm display manager, once it offers
some important security benefits over the traditional startx command.
.xsession-errors file log.