OpenBSD's man page afterboot(8) suggests: "You might wish to tighten up security more by editing /etc/fbtab as when installing X."
How might one do this? What lines when added to /etc/fbtab
would help to secure X Windows?
openbsdSecurityx11
OpenBSD's man page afterboot(8) suggests: "You might wish to tighten up security more by editing /etc/fbtab as when installing X."
How might one do this? What lines when added to /etc/fbtab
would help to secure X Windows?
I publish a signed package repository, and here's how it works.
The system administrator configures repositories by adding a configuration file such as /usr/local/etc/pkg/repos/JdeBP.conf
. As part of doing so, xe tells the package manager the public key that is to be used to check the signatures on the repository. Xe obtains this key from me in some suitably trusted fashion, and saves it in a file somewhere like /usr/local/etc/pkg/keys/JdeBP.pub
. Xe then names that as the public key file in /usr/local/etc/pkg/repos/JdeBP.conf
.
I sign the package repository with the private key that only I have using the command pkg repo . /elsewhere/package_signing_key
. This creates signed information about the repository and the packages in three files, meta.txz
, digests.txz
, and packagesite.txz
. Each of those archives has two files, one being a signature
file for the other. The digests and packagesite archives contain hashes of each of the package archive files. The meta archive just contains the names of the other two and some versioning of the pkg-ng tool information.
So this is very much like Secure APT. There are some differences:
Release
giving the checksums for Packages
and Packages
then giving the hashes for the actual package archives, pkg-ng has just one level. packagesite.yaml
gives the hashes of the actual package archives directly.Release
and Release.gpg
files, and then further Packages
and Sources
files, the packagesite.yaml
file (covering the entire repository) and its signature
are downloaded as a unit in one fetch
operation (and one HTTP/FTP transaction) as the packagesite.txz
file.But the idea is much the same. A system administrator trusts that the packagesite.yaml
file came from me because its accompanying signature
can be checked against the locally stored, trusted, copy of my public key. A system administrator trusts that the redo-1.3.txz
file came from me because its hash matches the hashes from the (now) trusted packagesite.yaml
.
Ports are a very different kettle of fish. Debian's Secure APT treats source packages as just more packages. FreeBSD/TrueOS ports are not source packages in the Debian sense, but are rather automated ways of obtaining and building source packages that are published by someone else. A port is in essence a makefile with some instructions on where to fetch
source from. It has a list of the hash(es) of whatever is to be fetched.
The port itself comes from the FreeBSD or TrueOS repository, using either Subversion (if FreeBSD) or git (if TrueOS or FreeNAS). The standard ideas for trusting Subversion or git thus apply. On TrueOS, for example, the "remote" URL used when fetching the ports (themselves) with git is an HTTPS url for a GitHub repository that iXsystems vouches (in the TrueOS Handbook) is one that it owns.
So a system administrator trusts a port because xe has obtained it using a Subversion or git fetch that xe trusts. Xe trusts the source archive fetched by the port because it matches the hash listed in the (now) trusted port.
Debian's Release.gz
and Packages.gz
are pretty much in effect just ways to compress the HTTP transport. I've glossed over some other things that aren't to do with security, such as differences in how one is expected to handle multiple operating system releases.
Debian has moved towards how FreeBSD works over the years, and doesn't work like that wiki page says any more. Nowadays one has the hashes and the signature all in one, more like a FreeBSD repository, in an InRelease
file. This prevents a "tearing" problem that occurs when one downloads Release
and then Release.gpg
and the repository owner has updated the repository in between the two downloads, causing a signature mis-match.
(Debian only did things this way originally because it grew these things in stages over the years, each built upon the preceding mechanisms without changing them: first the Package
system, then the Release
mechanism on top of that, then the Release.gpg
mechanism on top of that.)
Also: FreeBSD has another, different, way of doing this which involves "fingerprints" and a signed digests
file (in the digests.txz
archive).
I've also glossed over the security considerations for the signing key, as that isn't really relevant to an answer that is discussing how this is like/unlike Secure APT. The requirements of private key security are general to the whole notion of signing things with public/private keys, and are independent of repository structures.
Best Answer
Let's assume the X11 is /dev/ttyC5 as suggested by Salil.
Example 1: Web server and desktop environment on the same machine
Let's also assume that you are running a web server on with sensitive data (owner is user 'www') in it and your desktop user has permission to work (read, write, execute) in that directory.
But for everything you intend to do on the desktop like mailing, listening to music, messaging or browsing has nothing to do with these files. Now GUIs want to make everything simpler, faster and overall more comfortable, so a misclick in Nautilus, Konqueror or some other file manager can accidentally delete a file, a misclick might even send data as an email attachment over the internet, you could accidentally share a file over the network etc. - all these dangers are one click away in graphical desktop environment whereas on the command line you would issue a command name with the fitting arguments for the same effect.
You could now use /etc/fbtab to let
login
tellchmod
to make that directory readonly for the owner, so none of your desktop users can accidentally delete anything, even though they are permitted to work in that directory when using the command line and only the owner 'www' (which should not have desktop access anyway) can read it:Example 2: Sensitive data for a local project only
Let's assume that you are working on a project with colleagues, who all have permission to log into your X11 desktop with their accounts. But they are supposed to only have access to the directory with your project in it via X11, because they are not very experienced with the command line and might unintentionally do something wrong, so you have the permissions very restrictive for that directory.
This entry changes it to rwx rwx r-x for X11:
Example 3: USB and floppy storage as backup disks
You want to restrict access to usb storage on /dev/wd0 and /dev/wd1 as well as floppy disks on /dev/fd0, because they are used for backup only.