1047 lines
47 KiB
HTML
1047 lines
47 KiB
HTML
|
<!DOCTYPE html>
|
||
|
<html lang="en">
|
||
|
<head>
|
||
|
<meta charset=utf-8>
|
||
|
<title>SecBSD Docs</title>
|
||
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||
|
<meta name="description" content="SecBSD Docs">
|
||
|
<link rel="canonical" href="https://secbsd.org/">
|
||
|
<link rel="stylesheet" href="secbsd.css">
|
||
|
<!--
|
||
|
Copyright (c) 2005-2009 Steven Mestdagh <steven@openbsd.org>
|
||
|
|
||
|
Permission to use, copy, modify, and distribute this documentation for
|
||
|
any purpose with or without fee is hereby granted, provided that the
|
||
|
above copyright notice and this permission notice appear in all copies.
|
||
|
|
||
|
THE DOCUMENTATION IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL
|
||
|
WARRANTIES WITH REGARD TO THIS DOCUMENTATION INCLUDING ALL IMPLIED
|
||
|
WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE
|
||
|
AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
|
||
|
DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
|
||
|
PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
|
||
|
TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
|
||
|
PERFORMANCE OF THIS DOCUMENTATION
|
||
|
-->
|
||
|
</head>
|
||
|
<body>
|
||
|
<header>
|
||
|
<nav>
|
||
|
<div>
|
||
|
<h1><a href="index.html">
|
||
|
<img src="/img/logo.png" alt="[SecBSD]"></a>
|
||
|
</h1>
|
||
|
</div>
|
||
|
<ul>
|
||
|
<li><a href="index.html">About</a></li>
|
||
|
<li><a href="download.html">Download</a></li>
|
||
|
<li><a class="active">Docs</a></li>
|
||
|
<li><a href="faq.html">Faq</a></li>
|
||
|
<li><a href="team.html">Team</a></li>
|
||
|
<li><a href="sponsors.html">Sponsors</a></li>
|
||
|
</ul>
|
||
|
</nav>
|
||
|
</header>
|
||
|
<div class="box docs">
|
||
|
<h3><span class="green">█</span> Documentation</h3>
|
||
|
<ul class="list">
|
||
|
<li><a href="#coc">Code of Conduct.</a></li>
|
||
|
<li><a href="#contributing">Contributing.</a></li>
|
||
|
<li><a href="#overview">Overview of the Installation Procedure.</a></li>
|
||
|
<li><a href="#checklist">Pre-installation Checklist.</a></li>
|
||
|
<li><a href="#downloading">Downloading SecBSD.</a></li>
|
||
|
<li><a href="#mkinstall">Creating Install Media.</a></li>
|
||
|
<li><a href="#install">Performing a Simple Install.</a></li>
|
||
|
<li><a href="#fdeinstall">Performing a Full Disk Encryption Install.</a></li>
|
||
|
<li><a href="#updates">Security Updates.</a></li>
|
||
|
<li><a href="#commands">Executing Commands as Another User.</a></li>
|
||
|
<li><a href="#pkgadd">Installing Packages.</a></li>
|
||
|
<li><a href="#pkgdelete">Removing Packages.</a></li>
|
||
|
<li><a href="#network">Network Configuration.</a></li>
|
||
|
<li><a href="#wireless">Wireless Networking.</a></li>
|
||
|
<li><a href="#xfce">Install and configuration XFCE.</a></li>
|
||
|
</ul>
|
||
|
<h3 id="coc"><span class="green">█</span> Code of Conduct</h3>
|
||
|
<p>
|
||
|
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.<br><br>
|
||
|
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.<br><br>
|
||
|
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.<br><br>
|
||
|
Respect the opinion, attitude, background, preferences, traits
|
||
|
and human aspects of others.<br><br>
|
||
|
Do not discriminate others, based on any and all aspects - whether
|
||
|
negative or positive.<br><br>
|
||
|
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.<br><br>
|
||
|
Try to substantiate shared information and opinions rather than stating
|
||
|
your opinion as-if it were a fact.
|
||
|
</p>
|
||
|
<h3 id="contributing"><span class="green">█</span> Contributing</h3>
|
||
|
<p class="purple">
|
||
|
Contribute your expertise and hacking skills by using the
|
||
|
<a href="https://code.laylo.cloud/SecBSD/src">-current branch of
|
||
|
SecBSD.</a><br>
|
||
|
Whether you contribute to the code base or <a href="https://code.laylo.cloud/SecBSD/ports">port development</a>,
|
||
|
make sure to use -current.<br>
|
||
|
<h3>Requirements</h3>
|
||
|
<p>
|
||
|
1. A computer running the last snapshot of SecBSD:
|
||
|
<a href="https://mirror.secbsd.org/pub/SecBSD/snapshots/amd64/">amd64</a>
|
||
|
| <a href="https://mirror.secbsd.org/pub/SecBSD/snapshots/arm64/">arm64</a><br><br>
|
||
|
2. A code editor of your liking (ed, vi, vim, emacs, nano, etc)<br><br>
|
||
|
3. If an port does not exist for SecBSD. The first thing to do
|
||
|
is ask to <a href="mailto:purplerain@secbsd.org">Purple Rain</a>
|
||
|
or <a href="mailto:h3artbl33d@secbsd.org">h3artbl33d</a>
|
||
|
if anyone is working on the port -- there may be one in progress.
|
||
|
If no such port exists, then you may be the maintainer.<br><br>
|
||
|
4. (Optional) clone the repository that best fits your idea.
|
||
|
You might want to look at the <a href="https://github.com/freebsd/freebsd-ports">FreeBSD ports</a>
|
||
|
or <a href="https://github.com/NetBSD/pkgsrc">NetBSD pkgsrc</a>
|
||
|
for inspiration.<br><br>
|
||
|
5. Submit your work by contacting a core member. We do require
|
||
|
at least one core member signing off commits.
|
||
|
</p>
|
||
|
<h3><span class="green">█</span> Things worth noting</h3>
|
||
|
<p>
|
||
|
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.<br><br>
|
||
|
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.<br><br>
|
||
|
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.
|
||
|
</p>
|
||
|
<h3 id="overview"><span class="green">█</span>
|
||
|
Overview of the Installation Procedure
|
||
|
</h3>
|
||
|
<p>
|
||
|
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.
|
||
|
</p>
|
||
|
<p class="purple">
|
||
|
The ramdisk kernel can be booted from a number of different sources:
|
||
|
<br><br>
|
||
|
CD/DVD<br>
|
||
|
USB drive<br>
|
||
|
An existing partition<br>
|
||
|
Over the network<br>
|
||
|
(<a href="#PXE">PXE</a> or other
|
||
|
<a href="https://man.openbsd.org/diskless">network boot options</a>)<br>
|
||
|
Floppy disk<br>
|
||
|
Not every <a href="#">platform</a> supports all of these options.
|
||
|
</p>
|
||
|
<p>
|
||
|
If you have a running SecBSD system, bsd.rd is all you need to
|
||
|
reinstall or upgrade to a newer version.
|
||
|
To do so,
|
||
|
<a href="#Download">download and verify</a> the new <code>bsd.rd</code>,
|
||
|
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.
|
||
|
</p>
|
||
|
<p class="purple">
|
||
|
Booting from bsd.rd on an amd64 system can be done like so:<br><br>
|
||
|
<pre class="cmdbox">
|
||
|
Using drive 0, partition 3.
|
||
|
Loading......
|
||
|
probing: pc0 com0 com1 mem[638K 1918M a20=on]
|
||
|
disk: hd0+ hd1+
|
||
|
>> SecBSD/amd64 BOOT 3.33
|
||
|
boot> <b>bsd.rd</b>
|
||
|
</pre>
|
||
|
<p class="purple">
|
||
|
This will boot the kernel named bsd.rd from the first partition
|
||
|
of the first recognized hard disk.<br><br>
|
||
|
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:<br><br>
|
||
|
<pre class="cmdbox">
|
||
|
Using drive 0, partition 3.
|
||
|
Loading......
|
||
|
probing: pc0 com0 com1 mem[638K 1918M a20=on]
|
||
|
disk: hd0+ hd1+
|
||
|
>> SecBSD/amd64 BOOT 3.33
|
||
|
boot> <b>boot hd1d:/bsd.rd</b>
|
||
|
</pre>
|
||
|
<p class="purple">
|
||
|
SecBSD boot loaders are documented in the architecture-specific
|
||
|
<a href="https://man.openbsd.org/boot.8">boot(8)</a> man pages.
|
||
|
</p>
|
||
|
<h3 id="checklist"><span class="green">█</span> Pre-installation
|
||
|
Checklist
|
||
|
</h3>
|
||
|
<p>
|
||
|
Before you start, you should have some idea what you want to end up with.
|
||
|
A few things worth considering beforehand:
|
||
|
</p>
|
||
|
<p>
|
||
|
Machine name.<br>
|
||
|
Hardware installed and available:<br><br>
|
||
|
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:
|
||
|
</p>
|
||
|
<b class="purple">[</b><a href="#">amd64</a><b class="purple">]</b>
|
||
|
<p>If wireless internet is your only option, does your card require
|
||
|
<a href="https://ftp.secbsd.org/firmware/">additional firmware</a>
|
||
|
If so, you'll need to manually download it to a USB drive or similar
|
||
|
device, then use the
|
||
|
<a href="https://man.openbsd.org/fw_update">fw_update(1)</a> tool to
|
||
|
enable it after SecBSD is installed.
|
||
|
</p>
|
||
|
<p class="purple">Install method to be used.<br>
|
||
|
Desired disk layout:<br>
|
||
|
<ul class="list">
|
||
|
<li>Does existing data need to be saved elsewhere?
|
||
|
<li>Will SecBSD coexist on this system with another OS?
|
||
|
If so, how will each system be booted?
|
||
|
Will you need to install a boot manager?
|
||
|
<li>Will the entire disk be used for SecBSD, or do you want to
|
||
|
keep an existing partition/OS (or space for a future one)?
|
||
|
<li>How do you wish to sub-partition the SecBSD part of your disk?
|
||
|
<li>Do you want <a href="faq14.html#softraidFDE">disk encryption</a>?
|
||
|
</ul>
|
||
|
<p>
|
||
|
Network settings, if not using DHCP:
|
||
|
<ul class="list">
|
||
|
<li>Domain name and DNS address
|
||
|
<li>IP address and subnet masks for each NIC
|
||
|
<li>Gateway address
|
||
|
</ul>
|
||
|
<h3 id="downloading"><span class="green">█</span>
|
||
|
Downloading SecBSD
|
||
|
</h3>
|
||
|
<p>
|
||
|
The following installation images are available:
|
||
|
<ul class="list">
|
||
|
<li>
|
||
|
<b>install14.img</b>
|
||
|
<b class="purple">[</b><a href="https://mirror.secbsd.org/pub/SecBSD/snapshots/amd64/install14.img">amd64</a><b class="purple">]</b>
|
||
|
<br>
|
||
|
A disk image that can be written to a USB flash drive or similar device.
|
||
|
<br>
|
||
|
Includes the <a href="#FilesNeeded">file sets</a>.
|
||
|
<p>
|
||
|
<li>
|
||
|
<b>miniroot14.img</b>
|
||
|
<b class="purple">[</b><a href="https://mirror.secbsd.org/pub/SecBSD/snapshots/amd64/miniroot14.img">amd64</a><b class="purple">]</b>
|
||
|
<br>
|
||
|
The same as above, but file sets are not included.
|
||
|
They can be pulled down from the internet or from a local disk.
|
||
|
<p>
|
||
|
<li>
|
||
|
<b>install14.iso</b>
|
||
|
<b class="purple">[</b><a href="https://mirror.secbsd.org/pub/SecBSD/snapshots/amd64/install14.iso">amd64</a><b class="purple">]</b>
|
||
|
<br>
|
||
|
An ISO 9660 image that can be used to create an install CD/DVD.
|
||
|
<br>
|
||
|
Includes the file sets.
|
||
|
<p>
|
||
|
<li>
|
||
|
<b>cd14.iso</b>
|
||
|
<b class="purple">[</b><a href="https://mirror.secbsd.org/pub/SecBSD/snapshots/amd64/cd14.iso">amd64</a><b class="purple">]</b>
|
||
|
<br>
|
||
|
The same as above, but file sets are not included.
|
||
|
<p>
|
||
|
<li>
|
||
|
<b>floppy14.img</b>
|
||
|
<b class="purple">[</b><a href="https://mirror.secbsd.org/pub/SecBSD/snapshots/amd64/floppy14.img">amd64</a><b class="purple">]</b>
|
||
|
<br>
|
||
|
Supports some older machines that lack other booting options.
|
||
|
</ul>
|
||
|
<p class="purple">
|
||
|
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 <a href="https://man.openbsd.org/sha256">sha256(1)</a> command.
|
||
|
</p>
|
||
|
<p>
|
||
|
<pre class="cmdbox">
|
||
|
$ <b>sha256 -C SHA256 miniroot*.img</b>
|
||
|
(SHA256) minirootXX.img: OK
|
||
|
</pre>
|
||
|
<p class="purple">Or, if you're using an OS with the GNU coreutils:</p>
|
||
|
<pre class="cmdbox">
|
||
|
$ <b>sha256sum -c --ignore-missing SHA256</b>
|
||
|
minirootXX.img: OK
|
||
|
</pre>
|
||
|
<p class="purple">However, this only checks for accidental corruption.
|
||
|
You can use <a href="https://man.openbsd.org/signify">signify(1)</a> and the
|
||
|
SHA256.sig file to cryptographically verify the downloaded image.
|
||
|
</p>
|
||
|
<pre class="cmdbox">
|
||
|
$ <b>signify -Cp /etc/signify/secbsd-14-base.pub -x SHA256.sig install14.img</b>
|
||
|
Signature Verified
|
||
|
install14.img: OK
|
||
|
</pre>
|
||
|
<p class="purple">
|
||
|
Note that the signify package on other operating systems may not include the
|
||
|
required <a href="#">
|
||
|
public key</a>, or it may be installed in another location.
|
||
|
</p>
|
||
|
<p>The installXX.iso and installXX.img images do not
|
||
|
contain an <code>SHA256.sig</code> file, so the installer will complain that
|
||
|
it can't check the signature of the included sets:
|
||
|
</p>
|
||
|
<pre class="cmdbox">
|
||
|
Directory does not contain SHA256.sig. Continue without verification? [no]
|
||
|
</pre>
|
||
|
<p>
|
||
|
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.<br><br>
|
||
|
If the image's signature has been verified beforehand, it is safe to answer
|
||
|
"yes" at that prompt.
|
||
|
</p>
|
||
|
<h3 id="mkinstall"><span class="green">█</span> Creating Install
|
||
|
Media
|
||
|
</h3>
|
||
|
<h2>Flash Drive</h2>
|
||
|
<p>
|
||
|
A bootable USB flash drive can be created by attaching the target device and
|
||
|
copying over the image with <a href="https://man.openbsd.org/dd">dd(1)</a>.
|
||
|
</p>
|
||
|
<p class="purple">
|
||
|
Using SecBSD, assuming the device was recognized as sd1:
|
||
|
</p>
|
||
|
<pre class="cmdbox">
|
||
|
# <b>dd if=install14.img of=/dev/rsd1c bs=1m</b>
|
||
|
</pre>
|
||
|
<p class="purple">
|
||
|
Note that the <b>raw I/O device</b> is used, rsd1c rather than
|
||
|
sd1c.
|
||
|
</p>
|
||
|
<p class="purple">
|
||
|
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.
|
||
|
</p>
|
||
|
<h2>CD-ROMs</h2>
|
||
|
<p>
|
||
|
You can create a bootable CD-ROM on SecBSD by using
|
||
|
<a href="https://man.openbsd.org/cdio">cdio(1)</a>.
|
||
|
<pre class="cmdbox">
|
||
|
# <b>cdio tao cd*.iso</b>
|
||
|
</pre>
|
||
|
<h3 id="install"><span class="green">█</span> Performing
|
||
|
a Simple Install
|
||
|
</h3>
|
||
|
<p>
|
||
|
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 <code><Enter></code> to get
|
||
|
a good SecBSD install, moving your hands to the rest of the keyboard
|
||
|
only to enter the root password.
|
||
|
</p>
|
||
|
<p class="purple">
|
||
|
After the <a href="https://man.openbsd.org/dmesg">dmesg(8)</a> is shown,
|
||
|
you will see the first installer question:
|
||
|
<pre class="cmdbox">
|
||
|
...
|
||
|
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?
|
||
|
</pre>
|
||
|
<p class="purple">
|
||
|
Choose <code>(I)nstall</code> and follow the instructions.
|
||
|
</p>
|
||
|
<p>
|
||
|
<h2>File Sets</h2>
|
||
|
<dl>
|
||
|
<dt><code>bsd</code>
|
||
|
<dd>The kernel <b>(required)</b>
|
||
|
<dt><code>bsd.mp</code>
|
||
|
<dd>The multi-processor kernel (only on some platforms)
|
||
|
<dt><code>bsd.rd</code>
|
||
|
<dd>The <a href="#bsd.rd">ramdisk kernel</a>
|
||
|
<dt><code>baseXX.tgz</code>
|
||
|
<dd>The base system <b>(required)</b>
|
||
|
<dt><code>compXX.tgz</code>
|
||
|
<dd>The compiler collection, headers and libraries
|
||
|
<dt><code>manXX.tgz</code>
|
||
|
<dd>Manual pages
|
||
|
<dt><code>gameXX.tgz</code>
|
||
|
<dd>Text-based games
|
||
|
<dt><code>xbaseXX.tgz</code>
|
||
|
<dd>Base libraries and utilities for X11
|
||
|
(requires <code>xshareXX.tgz</code>)
|
||
|
<dt><code>xfontXX.tgz</code>
|
||
|
<dd>Fonts used by X11
|
||
|
<dt><code>xservXX.tgz</code>
|
||
|
<dd>X11's X servers
|
||
|
<dt><code>xshareXX.tgz</code>
|
||
|
<dd>X11's man pages, locale settings and includes
|
||
|
</dl>
|
||
|
<b class="purple">New users are recommended to install all of them.</b>
|
||
|
<p>
|
||
|
Some libraries from <code>xbaseXX.tgz</code>, 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 <code>xfontXX.tgz</code> or
|
||
|
font packages.
|
||
|
For the sake of simplicity, the developers decided against maintaining a minimal
|
||
|
<code>xbaseXX.tgz</code> set that would allow most non-X ports to run.
|
||
|
</p>
|
||
|
<h3 id="fdeinstall"><span class="green">█</span> Performing
|
||
|
a Full Disk Encryption Install
|
||
|
</h3>
|
||
|
<p>
|
||
|
Much like RAID, full disk encryption in SecBSD is handled by the
|
||
|
<a href="https://man.openbsd.org/softraid">softraid(4)</a> subsystem and
|
||
|
<a href="https://man.openbsd.org/bioctl">bioctl(8)</a> 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 <b>not supported</b> at this time.
|
||
|
</p>
|
||
|
<p class="purple">
|
||
|
Select (S)hell at the initial prompt.
|
||
|
<pre class="cmdbox">
|
||
|
Welcome to the SecBSD/amd64 1.3 installation program.
|
||
|
(I)nstall, (U)pgrade, (A)utoinstall or (S)hell? <b>s</b>
|
||
|
</pre>
|
||
|
<p class="purple">
|
||
|
From here, you'll be given a shell within the live environment to manipulate
|
||
|
the disks.
|
||
|
For this example, we will install to the <code>sd0</code> SATA drive, erasing
|
||
|
all of its previous contents.
|
||
|
<p class="purple">
|
||
|
Since the installer does not have many device nodes by default, make
|
||
|
sure the <code>/dev/sd0</code> device exists:
|
||
|
<pre class="cmdbox">
|
||
|
# <b>cd /dev && sh MAKEDEV sd0</b>
|
||
|
</pre>
|
||
|
<p class="purple">
|
||
|
You may want to write random data to the drive first with something like the
|
||
|
following:
|
||
|
<pre class="cmdbox">
|
||
|
# <b>dd if=/dev/urandom of=/dev/rsd0c bs=1m</b>
|
||
|
</pre>
|
||
|
This 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.
|
||
|
<p class="purple">
|
||
|
Next, initialize the disk with
|
||
|
<a href="https://man.openbsd.org/fdisk">fdisk(8)</a> and create the softraid
|
||
|
partition with <a href="https://man.openbsd.org/disklabel">disklabel(8)</a>.
|
||
|
</p>
|
||
|
<p class="purple">
|
||
|
If you're booting from MBR, do:
|
||
|
<pre class="cmdbox">
|
||
|
# <b>fdisk -iy sd0</b>
|
||
|
</pre>
|
||
|
<p class="purple">
|
||
|
If you use GPT for UEFI booting, do:
|
||
|
<pre class="cmdbox">
|
||
|
# <b>fdisk -iy -g -b 960 sd0</b>
|
||
|
</pre>
|
||
|
<p class="purple">
|
||
|
Next, create the partition layout:
|
||
|
<pre class="cmdbox">
|
||
|
# <b>disklabel -E sd0</b>
|
||
|
Label editor (enter '?' for help at any prompt)
|
||
|
sd0> <b>a a</b>
|
||
|
offset: [64]
|
||
|
size: [39825135] <b>*</b>
|
||
|
FS type: [4.2BSD] <b>RAID</b>
|
||
|
sd0*> <b>w</b>
|
||
|
sd0> <b>q</b>
|
||
|
No label changes.
|
||
|
</pre>
|
||
|
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.
|
||
|
<p class="purple">
|
||
|
Now we can build the encrypted device on our "a" partition.
|
||
|
<pre class="cmdbox">
|
||
|
# <b>bioctl -c C -l sd0a softraid0</b>
|
||
|
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
|
||
|
</pre>
|
||
|
<p class="purple">
|
||
|
Instead of a passphrase, you may want to
|
||
|
<a href="#fdekeydisk">use a keydisk.</a><br>
|
||
|
Make sure the <code>/dev/sd1</code> device is accounted for:
|
||
|
<pre class="cmdbox">
|
||
|
# <b>cd /dev && sh MAKEDEV sd1</b>
|
||
|
</pre>
|
||
|
<p class="purple">
|
||
|
All data written to <code>sd1</code> will now be encrypted with AES in XTS mode.
|
||
|
<p class="purple">
|
||
|
As in the previous example, we'll overwrite the first megabyte of our new
|
||
|
pseudo-device.
|
||
|
<pre class="cmdbox">
|
||
|
# <b>dd if=/dev/zero of=/dev/rsd1c bs=1m count=1</b>
|
||
|
</pre>
|
||
|
<p class="purple">
|
||
|
Type exit to return to the main installer, then choose this new
|
||
|
device as the one for your installation.
|
||
|
<pre class="cmdbox">
|
||
|
[...]
|
||
|
Available disks are: sd0 sd1.
|
||
|
Which disk is the root disk? ('?' for details) [sd0] <b>sd1</b>
|
||
|
</pre>
|
||
|
<p class="purple">
|
||
|
You will be prompted for the passphrase on startup, but all other operations
|
||
|
should be handled transparently.
|
||
|
<h3 id="fdekeydisk"><span class="green">█</span> Using a Keydisk</h3>
|
||
|
<p class="purple">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.
|
||
|
</p>
|
||
|
<p class="purple">Initialize your keydisk with
|
||
|
<a href="https://man.openbsd.org/fdisk">fdisk(8)</a>, then use
|
||
|
<a href="https://man.openbsd.org/disklabel">disklabel(8)</a>
|
||
|
to create a 1 MB RAID partition for the key data.
|
||
|
If your keydisk is <code>sd1</code> and the drive you want to encrypt is
|
||
|
<code>sd0</code>, the output will look something like this:
|
||
|
<pre class="cmdbox">
|
||
|
# <b>bioctl -c C -k sd1a -l sd0a softraid0</b>
|
||
|
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
|
||
|
</pre>
|
||
|
<p class="purple">
|
||
|
You won't be prompted to enter a passphrase because you used a keydisk instead.
|
||
|
The keydisk must be inserted at startup time.
|
||
|
<p>You can backup and restore your keydisk using
|
||
|
<a href="https://man.openbsd.org/dd">dd(1)</a>:
|
||
|
<pre class="cmdbox">
|
||
|
# <b>dd bs=8192 skip=1 if=/dev/rsd1a of=backup-keydisk.img</b>
|
||
|
# <b>dd bs=8192 seek=1 if=backup-keydisk.img of=/dev/rsd1a</b>
|
||
|
</pre>
|
||
|
<h3 id="updates"><span class="green">█</span> Security Updates</h3>
|
||
|
<p>
|
||
|
When a critical bug is found, the fix will be committed to the -current tree
|
||
|
(and made available in <a href="faq5.html#Flavors">snapshot builds</a>)
|
||
|
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.
|
||
|
<br><br>
|
||
|
For the SecBSD base system, security fixes are normally applied to the
|
||
|
two most recent releases.
|
||
|
There are four options:
|
||
|
</p>
|
||
|
<p>
|
||
|
<ul class="list">
|
||
|
<li>
|
||
|
<b>Apply binary patches</b> - available on amd64.
|
||
|
<p class="purple">
|
||
|
If you're running a supported release of SecBSD, you can simply use
|
||
|
the <a href="https://man.openbsd.org/syspatch">syspatch(8)</a> 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
|
||
|
<a href="#">announce</a>
|
||
|
mailing list.
|
||
|
<p>
|
||
|
<li>
|
||
|
<b>Update your system to -stable</b>
|
||
|
<p class="purple">
|
||
|
Fetch (or update) your source tree with CVS or <a href="https://git.laylo.nl/secbsd">Git</a>,
|
||
|
then recompile the kernel and userland.
|
||
|
<p>
|
||
|
<li>
|
||
|
<b>Patch the affected files individually</b>
|
||
|
<p class="purple">
|
||
|
While applying fixes from the <a href="#">errata page</a>
|
||
|
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.
|
||
|
<p>
|
||
|
<li>
|
||
|
<b>Upgrade your system to -current</b>
|
||
|
<p class="purple">
|
||
|
As all fixes are applied to the -current code base, updating your system
|
||
|
to the latest <a href="faq5.html#Snapshots">snapshot</a> is a good way to
|
||
|
get all the fixes at once.
|
||
|
However, running -current is not for everyone.
|
||
|
</ul>
|
||
|
<p class="purple">
|
||
|
For third party software installed via <a href="faq15.html">packages</a>,
|
||
|
fixes are normally only applied to the most recent release.
|
||
|
There are three options:
|
||
|
<ul>
|
||
|
<li>
|
||
|
<b>Use binary packages</b> - available on amd64.
|
||
|
<p class="purple">
|
||
|
Binary packages for -stable are rebuilt only for security issues or other
|
||
|
major fixes.
|
||
|
Simply call <a href="https://man.openbsd.org/pkg_add">pkg_add(1)</a> with
|
||
|
the <code>-u</code> flag to get the new files.
|
||
|
<p>
|
||
|
<li>
|
||
|
<b>Use the -stable ports tree</b>
|
||
|
<p class="purple">
|
||
|
Fetch (or update) your <a href="ports/ports.html">ports tree</a>,
|
||
|
run the <code>/usr/ports/infrastructure/bin/pkg_outdated</code> script to
|
||
|
list any packages in need of rebuilding, and issue <code>make update</code>
|
||
|
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
|
||
|
<a href="#">ports-changes</a>
|
||
|
mailing list.
|
||
|
<p>
|
||
|
<li>
|
||
|
<b>Upgrade your system to -current</b>
|
||
|
<p class="purple">
|
||
|
Binary packages for -current are rebuilt on a regular basis, and these
|
||
|
new packages will include any security fixes.
|
||
|
</ul>
|
||
|
<h3 id="commands"><span class="green">█</span> Executing Commands
|
||
|
as Another User
|
||
|
</h3>
|
||
|
<p>
|
||
|
The <a href="https://man.openbsd.org/doas">doas(1)</a> 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.
|
||
|
</p>
|
||
|
<p class="purple">
|
||
|
For example, if appropriately configured, the following command would display
|
||
|
root's <a href="https://man.openbsd.org/crontab.5">crontab(5)</a> file:
|
||
|
<pre class="cmdbox">
|
||
|
$ <b>doas -u root crontab -l</b>
|
||
|
</pre>
|
||
|
<p class="purple">
|
||
|
Commands invoked by <a href="https://man.openbsd.org/doas">doas(1)</a>
|
||
|
are logged to <code>/var/log/secure</code> by default.
|
||
|
Check the <a href="https://man.openbsd.org/doas.conf">doas.conf(5)</a> manual
|
||
|
for configuration examples.
|
||
|
<h3>Introduction</h3>
|
||
|
<p>
|
||
|
There are many applications one might want to use on an SecBSD system.
|
||
|
To make this software easier to install and manage, it is <i>ported</i>
|
||
|
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.
|
||
|
</p>
|
||
|
<p>
|
||
|
The ports collection does <b>not</b> 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.
|
||
|
</p>
|
||
|
<p>
|
||
|
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.
|
||
|
</p>
|
||
|
<p>
|
||
|
Packages can be easily managed with the help of several utilities:
|
||
|
<ul class="list">
|
||
|
<li><a href="https://man.openbsd.org/pkg_add">pkg_add(1)</a>
|
||
|
- for installing and upgrading packages
|
||
|
<li><a href="https://man.openbsd.org/pkg_check">pkg_check(8)</a>
|
||
|
- for checking the consistency of installed packages
|
||
|
<li><a href="https://man.openbsd.org/pkg_delete">pkg_delete(1)</a>
|
||
|
- for removing installed packages
|
||
|
<li><a href="https://man.openbsd.org/pkg_info">pkg_info(1)</a>
|
||
|
- for displaying information about packages
|
||
|
</ul>
|
||
|
<p>
|
||
|
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 <i>dependencies</i> 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.<br><br>
|
||
|
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:
|
||
|
</p>
|
||
|
<p>
|
||
|
<ul class="list">
|
||
|
<li>Different checks: has the package already been installed, or does it
|
||
|
conflict with other installed packages or file names?
|
||
|
<li>Dependencies which are not yet present on the system are automatically
|
||
|
fetched and installed before proceeding with the installation of the
|
||
|
package.
|
||
|
<li>Information about the package(s) is recorded in a central repository,
|
||
|
located in <code>/var/db/pkg</code> 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.
|
||
|
</ul>
|
||
|
<h3 id="pkgadd"><span class="green">█</span> Installing Packages</h3>
|
||
|
<p class="purple">
|
||
|
The <a href="https://man.openbsd.org/pkg_add">pkg_add(1)</a> 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.
|
||
|
<pre class="cmdbox">
|
||
|
# <b>pkg_add rsync</b>
|
||
|
Ambiguous: choose package for rsync
|
||
|
a 0: <None>
|
||
|
1: rsync-3.1.2p0
|
||
|
2: rsync-3.1.2p0-iconv
|
||
|
Your choice:
|
||
|
</pre>
|
||
|
<p class="purple">
|
||
|
Here you would select <b>1</b> if you want the standard package or <b>2</b>
|
||
|
if you need iconv support.
|
||
|
You can also choose the flavor directly on the command line by using
|
||
|
<code>pkg_add rsync--</code> (for the default) or
|
||
|
<code>pkg_add rsync--iconv</code> (for the iconv flavor).
|
||
|
</p>
|
||
|
<p>
|
||
|
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.
|
||
|
</p>
|
||
|
<p class="purple">
|
||
|
For some packages, important additional information will be given about
|
||
|
the configuration or use of the application.
|
||
|
<pre class="cmdbox">
|
||
|
# <b>pkg_add jove</b>
|
||
|
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 crash
|
||
|
</pre>
|
||
|
Additionally, some packages provide configuration and other information
|
||
|
in a file located in <code>/usr/local/share/doc/pkg-readmes</code>.
|
||
|
<p class="purple">
|
||
|
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.
|
||
|
</p>
|
||
|
<p>
|
||
|
Sometimes you may encounter an error like the one in the following example:
|
||
|
<pre class="cmdbox">
|
||
|
# <b>pkg_add xv</b>
|
||
|
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
|
||
|
</pre>
|
||
|
<p class="purple">
|
||
|
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.
|
||
|
</p>
|
||
|
<p>
|
||
|
There are several things to check:
|
||
|
<ul class="list">
|
||
|
<li>Your system may be incomplete: you did not install one of the
|
||
|
<a href="faq4.html#FilesNeeded">file sets</a> that contains the required
|
||
|
library.
|
||
|
<li>Your system (or packages) may be outdated: you have an older version
|
||
|
of the required library.
|
||
|
Make sure that both the base system and any installed packages are up to date.
|
||
|
<li>If you're running -current, base and package snapshots may be slightly
|
||
|
out of sync.
|
||
|
Wait for the mirrors to catch up and try again.
|
||
|
</ul>
|
||
|
<h2>Updating Packages</h2>
|
||
|
<p class="purple">
|
||
|
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:
|
||
|
<pre class="cmdbox">
|
||
|
# <b>pkg_add -u unzip</b>
|
||
|
unzip-5.52->unzip-5.52p0: ok
|
||
|
Read shared items: ok
|
||
|
</pre>
|
||
|
<p>
|
||
|
When a package has dependencies, they are also examined for updates.
|
||
|
Invoking <a href="https://man.openbsd.org/pkg_add">pkg_add(1)</a> with
|
||
|
only the <code>-u</code> flag will try to update all installed packages.
|
||
|
This is highly recommended over updating individual packages on their own.
|
||
|
</p>
|
||
|
<h3 id="pkgdelete"><span class="green">█</span> Removing Packages</h3>
|
||
|
<p class="purple">
|
||
|
To remove a package, simply take the name of the package and use
|
||
|
<a href="https://man.openbsd.org/pkg_delete">pkg_delete(1)</a>.
|
||
|
<pre class="cmdbox">
|
||
|
# <b>pkg_delete screen</b>
|
||
|
screen-4.0.3p6: ok
|
||
|
Read shared items: ok
|
||
|
</pre>
|
||
|
Again, modified configuration files will not be removed.
|
||
|
Unneeded dependencies can be trimmed by running <code>pkg_delete -a</code>
|
||
|
at any time.
|
||
|
<h3 id="network"><span class="green">█</span> Network Configuration</h3>
|
||
|
<p class="purple">
|
||
|
Network configuration in SecBSD is done with text files in <code>/etc</code>.
|
||
|
Typically, these settings are initially configured during the
|
||
|
<a href="faq4.html">installation process</a>.
|
||
|
<h2>Identifying and Setting Up Your Network Interfaces</h2>
|
||
|
<p class="purple">
|
||
|
Interfaces are named by the type of card, not the type of connection.
|
||
|
For example, here's a <a href="https://man.openbsd.org/dmesg">dmesg(8)</a>
|
||
|
snippet for an Intel Fast Ethernet network card:
|
||
|
<pre class="cmdbox">
|
||
|
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
|
||
|
</pre>
|
||
|
<p class="purple">
|
||
|
This device uses the <a href="https://man.openbsd.org/fxp">fxp(4)</a> driver
|
||
|
and is assigned the number 0 here.
|
||
|
<p class="purple">
|
||
|
You can find out what network interfaces have been identified by using the
|
||
|
<a href="https://man.openbsd.org/ifconfig">ifconfig(8)</a> utility.
|
||
|
The following command will show all network interfaces on a system.
|
||
|
<pre class="cmdbox">
|
||
|
$ <b>ifconfig</b>
|
||
|
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
|
||
|
</pre>
|
||
|
This sample shows only one physical Ethernet interface: <code>fxp0</code>.
|
||
|
An IP is configured on it, hence the values
|
||
|
<code>inet 10.0.0.38 netmask 0xffffff00 broadcast 10.0.0.255</code>.
|
||
|
The <code>UP</code> and <code>RUNNING</code> flags are also set on it.
|
||
|
<p class="purple">
|
||
|
The <a href="https://man.openbsd.org/netstart">netstart(8)</a> script configures
|
||
|
network interfaces at boot time using
|
||
|
<a href="https://man.openbsd.org/hostname.if">hostname.if(5)</a> files, where
|
||
|
"if" is replaced by the full name of each interface.
|
||
|
The example above would use the file <code>/etc/hostname.fxp0</code>, containing
|
||
|
the following options:
|
||
|
<pre class="cmdbox">
|
||
|
inet 10.0.0.38 255.255.255.0
|
||
|
</pre>
|
||
|
<p class="purple">
|
||
|
This <code>hostname.fxp0</code> file also has an interactive equivalent:
|
||
|
<pre class="cmdbox">
|
||
|
# <b>ifconfig fxp0 10.0.0.38 255.255.255.0</b>
|
||
|
</pre>
|
||
|
<p class="purple">
|
||
|
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:
|
||
|
<ul class="list">
|
||
|
<li><a href="https://man.openbsd.org/enc">enc(4)</a>
|
||
|
- Encapsulating interface
|
||
|
<li><a href="https://man.openbsd.org/lo">lo(4)</a>
|
||
|
- Loopback interface
|
||
|
<li><a href="https://man.openbsd.org/pflog">pflog(4)</a>
|
||
|
- Packet Filter logging interface
|
||
|
</ul>
|
||
|
<p class="purple">
|
||
|
Other virtual interfaces can be added with
|
||
|
<a href="https://man.openbsd.org/ifconfig">ifconfig(8)</a>'s <code>create</code>
|
||
|
subcommand.
|
||
|
<h3 id="wireless"><span class="green">█</span> Wireless Networking</h3>
|
||
|
<p class="purple">
|
||
|
SecBSD has support for
|
||
|
<a href="https://man.openbsd.org/?query=wireless&apropos=1">a number of
|
||
|
wireless chipsets</a>.
|
||
|
Further supported devices can be found in
|
||
|
<a href="https://man.openbsd.org/usb">usb(4)</a> and
|
||
|
<a href="https://man.openbsd.org/pci">pci(4)</a>.
|
||
|
The precise extent of their support is described in the driver man pages.
|
||
|
</p>
|
||
|
<p class="purple">
|
||
|
The following cards support Host-based Access Point (HostAP) mode, permitting
|
||
|
them to be used as a <a href="pf/example1.html">wireless access point</a>:
|
||
|
<ul class="list">
|
||
|
<li><a href="https://man.openbsd.org/acx">acx(4)</a>
|
||
|
- TI ACX100/ACX111
|
||
|
<li><a href="https://man.openbsd.org/ath">ath(4)</a>
|
||
|
- Atheros 802.11a/b/g
|
||
|
<li><a href="https://man.openbsd.org/athn">athn(4)</a>
|
||
|
- Atheros 802.11/a/g/n devices
|
||
|
<li><a href="https://man.openbsd.org/pgt">pgt(4)</a>
|
||
|
- Conexant/Intersil Prism GT Full-MAC 802.11a/b/g
|
||
|
<li><a href="https://man.openbsd.org/ral">ral(4)</a>
|
||
|
and <a href="https://man.openbsd.org/ural">ural(4)</a>
|
||
|
- Ralink Technology RT25x0 802.11a/b/g
|
||
|
<li><a href="https://man.openbsd.org/rtw">rtw(4)</a>
|
||
|
- Realtek 8180 802.11b
|
||
|
<li><a href="https://man.openbsd.org/rum">rum(4)</a>
|
||
|
- Ralink Technology RT2501USB
|
||
|
<li><a href="https://man.openbsd.org/wi">wi(4)</a>
|
||
|
- Prism2/2.5/3
|
||
|
</ul>
|
||
|
<p class="purple">
|
||
|
The <a href="https://man.openbsd.org/ifconfig">ifconfig(8)</a>
|
||
|
<code>media</code> 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 (<code>hostap</code>, <code>ibss</code>,
|
||
|
<code>monitor</code>).
|
||
|
For example, to see media capabilities of interface <code>ath0</code>, type:
|
||
|
<pre class="cmdbox">
|
||
|
$ <b>ifconfig ath0 media</b>
|
||
|
</pre>
|
||
|
<p class="purple">
|
||
|
In order to use some wireless cards, you will need to acquire firmware files
|
||
|
with <a href="https://man.openbsd.org/fw_update">fw_update(1)</a>.
|
||
|
Some manufacturers refuse to allow <a href="faq1.html#ReallyFree">free</a>
|
||
|
distribution of their firmware, so it can't be included with SecBSD.
|
||
|
<p>
|
||
|
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.
|
||
|
</p>
|
||
|
<h2>Configuring Your Wireless Adapter</h2>
|
||
|
<p class="purple">
|
||
|
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
|
||
|
<a href="https://man.openbsd.org/ifconfig">ifconfig(8)</a> utility.
|
||
|
</p>
|
||
|
<p class="purple">
|
||
|
An example of a <a href="https://man.openbsd.org/hostname.if">hostname.if(5)</a>
|
||
|
file for a wireless client might be:
|
||
|
<pre class="cmdbox">
|
||
|
nwid puffyuberalles wpakey passwordhere
|
||
|
dhcp
|
||
|
</pre>
|
||
|
<p class="purple">
|
||
|
Or, for multiple access points:
|
||
|
<pre class="cmdbox">
|
||
|
join home-net wpakey passwordhere
|
||
|
join work-net wpakey passwordhere
|
||
|
join cafe-wifi
|
||
|
dhcp
|
||
|
</pre>
|
||
|
<p class="purple">
|
||
|
Note that the <code>dhcp</code> 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.
|
||
|
</p>
|
||
|
<h2>Trunking Your Wireless Adapter</h2>
|
||
|
<p class="purple">
|
||
|
Trunks are virtual interfaces consisting of one or more network interfaces.
|
||
|
In this section, our example will be a laptop with a wired
|
||
|
<a href="https://man.openbsd.org/bge">bge0</a> interface and a wireless
|
||
|
<a href="https://man.openbsd.org/iwn">iwn0</a> interface.
|
||
|
We will build a <a href="https://man.openbsd.org/trunk">trunk(4)</a> interface
|
||
|
using both of them.
|
||
|
</p>
|
||
|
<p>
|
||
|
To do this, we first activate the two physical ports, then assign them to
|
||
|
<code>trunk0</code>.
|
||
|
<pre class="cmdbox">
|
||
|
# <b>echo up > /etc/hostname.bge0</b>
|
||
|
</pre>
|
||
|
<p class="purple">
|
||
|
The wireless interface, however, needs a bit more configuration.
|
||
|
It will need to attach to our wireless WPA-protected network:
|
||
|
<pre class="cmdbox">
|
||
|
$ <b>cat /etc/hostname.iwn0</b>
|
||
|
nwid puffynet wpakey mysecretkey
|
||
|
up
|
||
|
</pre>
|
||
|
<p class="purple">
|
||
|
Now, our trunk interface is defined like this:
|
||
|
<pre class="cmdbox">
|
||
|
$ <b>cat /etc/hostname.trunk0</b>
|
||
|
trunkproto failover trunkport bge0
|
||
|
trunkport iwn0
|
||
|
dhcp
|
||
|
</pre>
|
||
|
The trunk is set up in <code>failover</code> mode,
|
||
|
so either interface can be used.
|
||
|
If both are available, it will prefer the <code>bge0</code> port,
|
||
|
since that is the first one added to the trunk device.
|
||
|
<h3 id="xfce"><span class="green">█</span> Installation and configuration XFCE.</h3>
|
||
|
<span class="green">By 0xdarkpadr3</span>
|
||
|
<h2>Setting doas</h2>
|
||
|
<p class="purple">
|
||
|
Login as root and create doas.conf file.
|
||
|
</p>
|
||
|
<pre class="cmdbox">
|
||
|
# <b>echo "permit keepenv :wheel" > /etc/doas.conf</b>
|
||
|
</pre>
|
||
|
<p class="purple">
|
||
|
Logout and then login as a user.
|
||
|
</p>
|
||
|
<h2>Installing Xfce</h2>
|
||
|
<pre class="cmdbox">
|
||
|
$ <b>doas pkg_add -v xfce xfce-extras consolekit2</b>
|
||
|
$ vi ~/.xsession and uncomment the line 14 exec /usr/local/bin/startxfce4 --with-ck-launch
|
||
|
$ save and quit :wq!
|
||
|
</pre>
|
||
|
<p class="purple">
|
||
|
<h2>Enable and start daemons</h2>
|
||
|
<pre class="cmdbox">
|
||
|
$ doas rcctl enable messagebus xenodm
|
||
|
$ doas rcctl start messagebus xenodm
|
||
|
$ doas reboot
|
||
|
</pre>
|
||
|
<p class="purple">
|
||
|
It is recommended to run X with the <code>xenodm</code> display manager, once it offers
|
||
|
some important security benefits over the traditional <a href="https://man.openbsd.org/startx">startx</a> command.
|
||
|
</p>
|
||
|
|
||
|
If you find any problems, read the <code>.xsession-errors</code> file log.
|
||
|
<h2>See also</h2>
|
||
|
<ul class="list">
|
||
|
<li>X Window System https://www.openbsd.org/faq/faq11.html</li>
|
||
|
<li>Xfce pkg-readme /usr/local/share/doc/pkg-readme/xfce</li>
|
||
|
<li>System Management https://www.openbsd.org/faq/faq10.html</li>
|
||
|
<li>General Questions https://www.openbsd.org/faq/faq8.html#locales</li>
|
||
|
<li>Xfce documentation https://docs.xfce.org</li>
|
||
|
</ul>
|
||
|
</div>
|
||
|
</body>
|
||
|
</html>
|