TRON-DELTA.ORG – TrueOS Core Security Review 2018


At present the TRON-DELTA.ORG commences a security review on TrueOS (, which includes a manual code and configuration review/audit (no static or dynamic code analysis) and a review of documentation as needed. It focuses on backdoors and obviously problematic or questionable things, within the TrueOS CORE sub-project.

Please note, that our organization has not yet found any backdoor whatsoever within the TrueOS CORE sub-project.

However, to conclude the security review a number of questions, directed to the TrueOS developers or TrueOS helpers, are listed below. We are aware of the high volume of questions, which probably will take some time to answer. However, we would greatly appreciate a short reply to all of the questions below, as soon as time permits, to conclude our security review and publish the final result. Thank you!

A review of the Lumina project as well as the SysAdm project will take place in due course. In addition to that extensive image/ISO testing will take place in February and March 2018. Depending on our resources the TRON-DELTA.ORG will also commence a FreeBSD and FreeBSD-ports project review, including code analysis.

Our organization migrated its server systems and firewalls from GNU/Linux to FreeBSD in the past. Unfortunately, after years of remastering and maintaining a dedicated GNU/Linux desktop distribution we were looking for something FreeBSD-based, that would integrate well into our IT infrastructure and satisfy our high demand for security.

Due to past developments, namely NSA and CIA leaks, the course of the Linux project development, two kernel repository compromises and Google commits to the Linux kernel master tree since version 3.3, we felt that Linux (unlike GNU which we support and value) would no longer satisfy that demand.

Users of the official TrueOS IRC channel on freenode suggested to post all review-related data on for transparency and ease of discussion. All links provided in this post are simply for reference. In case this forum is not the right place to post the information below, an administrator may move it to a more appropriate location, please.

Q#1: In essential-packages-iso there is a meta-package multimedia/webcamd referenced, which we would like to see removed for security reasons. Is it possible for Mr. Moore or some other TrueOS developer to do this?


Q#2: In port-make.conf there are ports configurations. Does TrueOS mainly use ports or rather pre-compiled packages via pkgsrc package management, derived from the NetBSD project? Also, several systems like PulseAudio and OSS (Wayland?) are referenced and configurations like emulators_wine_SET=HAL OPENAL CUPS, which we would like to see changed. Is that possible within the default TrueOS images for security reasons? Why is so much in commented out?


Q#3: The etc/profile does unlike in e.g. Ubuntu GNU/linux not load users ~/.bashrc files. Is that intended or can/may you change that? Does TrueOS work much differently under the hood here? Will .cshrc be synchronized with .bashrc (parameters like e.g. HISTORY [3f], secure UMASK, etc.) and will both be invoked centrally by a configuration file residing in /etc/?


Q#4: In we see the lines 8 and 10 with a lower memory limit of 256 MiB, which we think is highly undesirable and/or unlikely for todays desktop/server OS. Would you mind to increase that to at least 512 MiB as a safe level? Also we fount that in /pico-upgrade/etc/rc.local there are no contents. Is that intended?


Q#5: File root/.fluxbox/init indicates, that Lumina version 1.3/1.4 still requires fluxbox, although it should not. Is this legacy and potentially unsafe or do you provide them for genuine fluxbox users? We also see that the installer at least seem to start X11 and fluxbox and not Wayland and Non-fluxbox-Lumina? Can you clear things up a little here for us, please? How safe is fluxbox regadring privileges? X11 e.g. was rewritten years ago to require less root/sys privileges and drop them early in the code.


Q#6: Regarding Q#2 we realized, that KDE, GNOME [6d] and Lumina/fluxbox centric applications are used across the system. Is there an initiative to make this more homogenous in the future to reduce library code + configurations and thus attack vectors/exploitable flaws for better security? What is /root/.kde4/share/config/nitrogenrc in that context and is it required?


Q#7: In qt_assistantrc we think we found malformed content. Lines like e.g. no. 14 should not end with or contain: ^e We found this in multiple qt-related configuration files. Would someone please assess this and possibly correct/fix the issue?


Q#8: In installtrueos.desktop the file pc-sysinstaller is referenced in line 2. Unfortunately the link seems to be broken or the file non-existent. Maybe this was a temporary glitch. Can someone look into that, please and make sure everything is safe?


Q#9: In we found a reference to PC-BSD in line 6 (like in several other files) and a file creation in line 135, which we do not understand. Can someone please explain the implications of that statement? Also we found file .Xdefaults and /skel/Pictures/* to be empty. Is that intended and safe? Will file /pico-overlay/firstboot be removed after install/setup scripts were run?


Q#10: In some files there are references to PC-BSD (often in file heads) and some files are explicitly named after the legacy system, like install-overlay/pcbsd-media, pkg-descr or Makefile.trueos (links below), which could be a potential security hazard of permissions set elsewhere and executability preserved. What does INSTALLPACKAGESET=“EDGE” in /blob/master/ mean and what is /blob/…? Does XF86Config.virtualbox and xorg.conf.virtualbox really need to load the (unsafer) glx module? File [10l] refernces to outdated “PBI” in line 47.


Q#11: Wikipedia states Lumina does avoid Polkit! However, we (luckily) found a Polkit configuration file elsewhere (system.pkla). Would someone make a statement on that, please and confirm user level/GUI safety (very important)? Thank you!


Q#12: In .xinitrc we found no restriction of CTRL + ALT +BACKSPACE (Option “DontZap” “no”). Would you like to add that to the TrueOS image for security reasons?


Q#13: In we found in lines 69 and 72 that DHCP and WiFi/WLAN [13g] is installed during TrueOS installation, but also stays enabled per configuration statements after installation of the OS in TrueOS-Pico rc.conf and rc.conf.desktop or rc.conf.server. Is that truly intended for convenience? Would you please reassess that in conjunction with avahi (, reset-firewall), openNTPd, RPC/NFS and Ipv6 [13d, 13e, 13g], for security reasons? We also realized that file headers (line 1-6) are different from those in other files.


Q#14: In Lifepreserver is referenced in lines 56 to 69 (keys). Can you please point us to documentation which covers secure key management (where goes “${TMPDIR}/.geli-keys” later on?) and contains examples on how to open crypted OpenZFS volumes on arbitrary disks, e.g. after system hardware is destroyed, but crypted disks and data survived.


Q#15: In pc-sysinstall.conf we found line 66, which refers to 9.0-RELEASE, which seems to be obsolete. Also line 72 and 73 refer to non-existent home directories (john?). Would you like to fix that safely?


Q#16: In menu Fluxbox-0.1.14 is referenced, but v1.3.7 of the project is current. Does that pose a problem?


Q#17: In TrueOS-Pico rc.conf we found besides DHCP also NTPP enabled. In the past ntpd had several (mostly locally exploitable) security vulnerabilities. Therefore we would like to see a /etc/cron.daily/ntp with a line like “ntpdate -u >>/var/log/messages 2>&1”, for security reasons. That should be sufficient for 99.9% of all users. Further we realized syslogd is disabled (although enabled in /trueos-core/blob/master/xtrafiles/local/share/trueos/conf/rc.conf.desktop). Is that intended and why?


Q#18: File /pico-overlay/opt/settings.conf reminded us about X11 magic cookies. Has that security-related issue been addressed among TrueOS developers already?


Q#19: In /pico-overlay/opt/RPI2/setup line 7 sets a kernel system tunable/variable to 900 MHz. Is that obsolete or can someone explain why that is the case and extend the comment in line 6, please?


Q#20: In directory /pico-overlay/root/.config/pulse/ there are several runtime-generated files, which in e.g. c027d4121c44671776d98d7c58093a12-runtime contain machine-specific values like /tmp/pulse-u8mPm55LkBL4. Would you like to purge that from the installation iso for security reasons, please?


Q#21: In the default TrueOS desktop version are software like Mozilla Firefox, but also other user agents. Is there an /etc/alternatives configuration in TrueOS like in some GNU/Linux distribution? Will you reassess software based on security records? Adobe Flash, Mozilla Firefox and Thunderbird or Chrome and Safari as well as Java SE JRE are (partially) critical applications with a mixed security record. We strongly recommend to ultimately purge all flash-related content (e.g. blob/master/xtrafiles/local/share/trueos/desktop-defaults/usr/local/bin/flashpluginctl) from TrueOS.


Q#22: In devfs.rules we found all possible devices/paths be set to mode 666, thus readable and writable even for others. Is that intended or would you mind a change for improved security?


Q#23: In hosts.allow there is sendmail (line 50 to 54) set to allow, although the OpenRC service in TrueOS is disabled by default. We recommend to recommend this out (and all subsequent sections for other on-default services). In addition to that the EXAMPLE statement should be removed and a line like “portmap privoxy cupsd tor mountd nfsd statd lockd rquotad gpg-agent : ALL” nonetheless added to either hosts.deny (deprecated) or the hosts.allow file, since they never should be available to the outside. Which purpose does hosts.deniedssh serve for? What/where is the default configuration file for gpg-agent in /trueos-core?


Q#24: In /usr/local/etc/fscd.conf no services for FSCD reincarnation server are specified. Do you TrueOS devs think it would make sense to configure something there for improved system safety/stability?


Q#25: Should functionality not be a part of Lumina ( Could the shell script (and /usr/local/share/trueos/scripts/ be racy at some point/under some conditions? Would you like to implement a mutex or semaphore?


Q#26: In .xscreensaver fortune is referenced in line 41, as well as in several other files (see references below). Would you TrueOS devs mind to entirely purge that from the OS for security reasons? Further, has .xscreensaver ever be assessed for CPU consumption/LPS in MIPS/FLOPS?


Q#27: In it seems e.g. zArc definition in lines 55 to 64 does not take a memory upgrade e.g. from 2 GiB to 8 GiB into account. Will be recalled occasionally / at users will or only once, as stated in line 2 (first time init)? Is pc-updatemanager (line 112) a part of (which we haven’t yet audited) or where does that come from?


Q#28: In /trueos/xstartup/ it seems the PC speaker is disabled. Does TrueOS also ship something like /etc/modprobe.d/blacklist in GNU/linux with lines like “blacklist pcspkr”? Would you mind to add such a configuration (or equivalent) to TrueOS CORE, with most annoying, unsafe or insecure modules blacklisted initially?


Q#29: In as per line 8 the evaluation does not take UID 1000 into account (-gt is not equal to -ge), which may want GnuPG configured as well. We researched and found that FreeBSD indeed counts users/accounts with UID starting at 1000 (including 1000) as regular user accounts. Would you thus like to fix that control structure?


Q#30: Unfortunately we were unable to find checksums for the files on in the drop down menus. Would you mind to add an option for the drop down menus? Also does differentiate between unstable/ and master/ but not unstable/ and stable/. Is there a reason for that?



@TRON-DELTA : Thank you for looking into this!
I will go through your questions here and try to answer them one at a time…

Q1. webcamd
The “essential-packages-*” files in the trueos-core repo are used for our automated package build testing only: Those simply provide a list of packages that need to build properly and/or exist before a package repo build routine can be considered “successful” (from an automation/build standpoint - the QA processes get run later).

The “webcamd” package ( is just a collection of device drivers from Linux, and enable things like webcams, joysticks and such to be detected properly. We already have the options ( to hook into other system services such as HAL disabled for it (since HAL is a known security risk). Is there some other reason for that package to be “removed” from TrueOS?

Q2. Port Configurations
TrueOS uses the FreeBSD ports tree (not pkgsrc from NetBSD) as the “source of truth”, but we build/distribute pre-compiled packages for all those ports as a complete package repository rather than expect people to build everything from ports manually (this also works around the complexities of TrueOS being based on FreeBSD’s “Current” branch and the possibility of kernel ABI changes with every update).

The “port-make.conf” file in the trueos/trueos-core source repo is where we provide changes to the default build options for FreeBSD ports, and we are completely open to people submitting changes/updates to that as needed (it has been organically grown from the old PC-BSD days, so some things in it may be leftover from then and need to get disabled). For instance, I did not realize that we had any HAL options still enabled in there any more, and I just turned that off in the Wine packages for you.

The “install-overlay” directory is only used when creating the environment for the install ISO itself. Things in there do not get placed onto the installed/live system. That being said, there is a lot of KDE/Qt[3/4] cruft in there that is very stale (from the old PC-BSD days) and should probably get removed. We actually have a large cleanup of the trueos-core repo planned within the next month or so just to audit/remove all the old files that are not used anymore and to split things up between the trueos-[server/desktop] repos and tie things into the packages more easily.

Regarding - it is not commented out. The github color highlighter just gets messed up by some complicated “echo-ing” on lines 17-36 and lines 41-59 of that shell script.


This review seems to be a complex task within the development. Shouldn’t this content be moved to a new category named ‘Audit’ or something similar?


Q3: Bash settings
TrueOS does not install/use bash by default. On FreeBSD “csh” (or “tcsh”) are the default shells and /bin/sh is the real bourne shell and not a fake redirect to bash.
The shell environment config files (.cshrc, .bashrc, etc.) do not need to be loaded manually in /etc/profile, as each shell handles that individually when it is launched. That is why /etc/profile is so minimal - it only sets the bare minimum for consistency (LANG, EDITOR, PAGER, and BLOCKSIZE) across shells.

That file is a part of the installer *only and simply tries to detect/warn about less than 256 MB of memory when booting up the installer image. This does not impose any specific limitations/recommendations for the system, and as you pointed out we could probably bump that up to 512 MB or even 1 GB really trivially.

The pico-upgrade file has no contents because it is just a placeholder for a possible update script later (according to the commit that created it). I want to say that we could just get rid of that file because the update routine for the PICO eventually ended up someplace else - but I am not certain of that at the moment. With our cleanup of that repo we will work that out and remove it as needed.


Thanks for pointing that out @RJules3 : I just made a new “Security” category for topics and moved this over there.


Q5: Lumina and Fluxbox
Lumina 1.x still uses Fluxbox as the underlying window manager for the desktop (just as KDE uses kwin, GNOME uses metacity/mutter, etc…). Lumina 2.x is the version that removes Fluxbox and manages the entire session from a single binary and that version is scheduled to be released later this year.

Fluxbox is also used in the background of the TrueOS installer image (which is why the install overlay customizes the Fluxbox settings for that environment). Fluxbox itself is very minimal and only runs with user priviledges. It does not talk to any system-control services, use DBUS, or any of the other protocols that are common on Linux to modify the system. Fluxbox is really only designed to interface with the X11 display server and manage the graphical windows themselves - nothing else.

TrueOS only uses X11 at the moment. All the “WAYLAND” build options for ports are actually quite new and only used to allow applications to be compiled/used against either X11 or XWayland so that developers can start running/testing Wayland on FreeBSD here in the near future.

Q6: Other Desktops (KDE/GNOME/etc)
TrueOS itself only officially supports/installs the Lumina desktop, but users have the flexibility to install/use other desktops like KDE/GNOME post-install if they desire. The KDE configuration files in trueos-core are currently just leftovers from when PC-BSD was based around KDE and will be getting removed in the repo cleanup that was already mentioned.

As for the applications that TrueOS installs: All of them are desktop-agnostic and do not use the KDE/GNOME/other libraries. In fact, that was one of the reasons why we started creating the Lumina desktop. Both Lumina and TrueOS tools are written to be completely independent from the running desktop environment, and only use a common graphical toolkit (Qt5).


Q7: qt_assistantrc
That is a leftover file in the installer image/environment only. It is actually for Qt3, and silently ignored for the current version of Qt (5.x). Again, that will be removed by the repo cleanup here soon.

Q8: installtrueos.desktop
That file is actually correct. “pc-sysinstaller” is the name of the graphical install UI (front-end to “pc-sysinstall”) and only gets used within the installer environment itself (not on the live/installed system).

The PC-BSD references in comments in a number of these shell scripts are because TrueOS was formerly called PC-BSD (back when those shell scripts were written). We tried to find/replace all the public instances of PC-BSD with TrueOS when we made the name change, but for minor comments within scripts we just left those alone to preserve the history of the file.

The “.disable” file creation on line 135 is probably used by one of the other shell scripts in the installer-initialization chain. In the installer itself, there are a lot of chained-together shell scripts for setting up and starting the installer, and there are a number of cases where the creation of a sentinal file with “touch” (an empty file) is simply used to signal one of the other scripts about the current status. Since the installer environment itself is separate from the “installed” environment (and the installer environment is started in a clean state on every boot) we can use this method fairly trivially.

The empty “.Xdefaults” for the installer environment was used to remove the FreeBSD-default file (if my memory is correct). The installer environment is carefully cleaned/prepared for fully-scriptable changes and I think this was one of those cleanup methods to avoid changes from upstream FreeBSD corrupting the environment. As far as the empty “Pictures” directory - that was the old method whereby we ensured that some standard directories were automatically created in a new user’s home dir (the “/usr/share/skel” directory is the template for new user home directories). We have actually been moving over to a more rigerous method which takes localization into account, so this dir will probably be getting removed here soon.

As far as the “pico-overlay/firstboot” file is concerned: Yes I think it either gets removed after getting run or gets ignored on subsequent boots based upon the existance of other files on the system which get created at first boot.


Q10: More PC-BSD and Xorg configure templates
The PC-BSD comments/headers: the history of TrueOS is that is was PC-BSD, and many of the backend/hidden scripts still use pcbsd in various places that are not user-apparent. Since the project name is not tied to any actual users/groups on the system, there are no permission/executable issues from the change.

The INSTALLPACKAGESET=“EDGE” and other blob files are tied into our Jenkins automation systems. That “EDGE” value is a placeholder (old name for the UNSTABLE repo) which gets automatically replaced by the build system depending on if it is creating a STABLE or UNSTABLE install image so the installed system is pointing at the correct package repository out-of-box.

The Xorg configuration templates are already unused. We have been moving all of these systems over to the trueos-utils-qt5 utility, and many of the templates were removed/replaced during the conversion.

The “PBI” comment in is just a hidden comment without any action. I believe that entire file is on the chopping block for the repo cleanup (the entire xstartup folder is the old methods from PC-BSD).

Q11: Lumina and PolicyKit
That policykit file is a leftover from the old PC-BSD days where KDE was used (and needed polkit). That is not used any more by default, but it it is still installed in case people still try to use KDE/GNOME so that users can shutdown/reboot the system if they are in the “operator” group (that ability is there, that polkit file just lets KDE/GNOME know about it).

Q12: Ctrl-Alt-Backspace
That file is part of the environment setup for the installer - not the installed system. In that situation I believe the graphical installer is setup to be automatically restarted if the graphical session dies unexpectedly and the installer environment provides easy access to a root terminal anyway - so while we could turn that option on for you I don’t think it will have any security ramifications.

Q13: Networking
Yes, the installer environment and the installed environment are both setup for DHCP out of box so that internet connections can be utilitized as need. In the case of the installer, a network connection may be used to restore a system from a remote backup rather than only allowing a “fresh install” of TrueOS. The same goes for the installed system because the end-user experience is that plugged-in internet connections should “just work”. Note that the DHCP settings will only work for wired connections out of box. Wireless connections still require a couple manual steps by the end user to select/connect to an access point.

As far as avah goes, we are actually in the process of removing this piece of Linux-ware and replacing it with a built-in “openmdns” service from OpenBSD. This will allow for the MDNS registration/receive without all the extra overhead of DBUS and other Linux stuff and we will move the PICO detection mechanisms over to that when it is finished.

We are open to conversations about changing the default networking setup as needed, so if you submit a pull request to the repo (or open a bug ticket where we can have the discussion) then we can talk with you about that and make a decision as needed.


Q14: Life Preserver Keys
This file in particular is used when restoring a life-preserver-based system backup from a remote system. That script is used to load an SSH key from an alternate USB drive into memory so that it can be used to connect to the remote system to fetch the system backup. The key is only loaded into memory (tmpfs) and flushed/discarded as soon as the system (the installer environment) is rebooted.

This is completely unrelated to GELI or encrypted partitions.

Q15: Old Release Environment Variables
Those variables were not getting used and there more as examples, but I did just comment those out for you.

Q16: Fluxbox Version in menu config
The Fluxbox menu configuration file has not changed much in a long time, and that version of Fluxbox is just a comment about which version it was created on. I just removed it for you though.

General Info about PICO
The TrueOS PICO is a minimalized install image for a Raspberry Pi (or similar ARM board - but the Pi is the only one we have built so far I think).
It is a plain FreeBSD install (11.0-Release?), which is automatically setup to connect to the internet (DHCP) discover a Pico Server on the local network, and provide a graphical interface to that system. Nothing is saved/run on the PICO system itself - it is just a remote graphical terminal to some other graphical system on the network.

Q17: PICO Networking
Since the backbone of the PICO is the network, DHCP and NTPD are the two primary methods used to connect/enable the remote access. The local PICO system is essentially not used and no access to it is provided to the end user, so I am not sure how useful it will be to dump logs onto the rather fragile SD card.

Q18: X11 Magic Cookies
Both PICO and TrueOS/PCDM do not use XDMCP. That PICO config file was just a placeholder while Kris was playing around with different mechanisms for doing the remote-access.

Q19: PICO 900 MHz Tunable
That is a specific tunable for the Raspberry Pi 2 board to enable the best performance on that platform (which is why it is in the “RPI2” directory). Since the PICO is a static appliance, that tunable will be pre-set for each of the individual hardware platforms based on the capabilities as needed.

Q20: PICO Pulse
I just asked Kris about that one and it looks like they were committed to the repo by accident.
Files removed!


Q21: Web Browsers and Flash
I am not quite sure what you are asking about regarding browsers. TrueOS only pre-installs the QupZilla browser (uses Qt5-webengine - a slimmed down version of the “blink” fork of Chromium). All the other major browsers (and a bunch of minor ones) are available in the package repository (since they have been ported to work on FreeBSD), but we make no distinction/requirement about any of them.

The “flashpluginctl” script was something from many years back when the Flash plugin was essential for people. I just removed that file since we have not been able to use for a while now since Firefox disabled NPAPI plugins in general.

Q22: devfs rules
We are open to discussions about how to change/enhance device security. Please open a bug ticket or send in a pull request to start the conversation.

Q23: hosts.allow
hosts.deniedssh is parsed/loaded from line 93 in hosts.allow, and provides a simple way to automatically add blacklisted IP addresses to the rules by other services/scripts without worrying about parsing the rather complicated hosts.allow file.
As far as your other recommended changes, please send in a pull request with those so that we can discuss/evaluate them.

Q24: fscd
The fscd utility is not needed on TrueOS because OpenRC already handles all service states and automatic restarts. When something like this is part of upstream FreeBSD we tend to just disable it rather than remove it so that our changes to FreeBSD itself are kept to a minimum.

This is an old script that was used to launch the PC-BSD tray utilities on all window managers and desktops. It has already been deactivated now that we have Lumina and the XDG autostart spec is used instead, but these old files in the repo have not been purged yet.

Q26: xscreensaver
We would not mind removing that - please send in a pull request with the necessary changes.
XScreensaver is actually on the “purge” list along with Fluxbox for Lumina 2.x, so I anticipate that those config files will not be in existance in the repo for much longer anyway.

Q27: Memory Upgrades and zArc
The “sys-init” script is only run the first time a system is booted after an installation (part of our first-time setup wizard/routine). “pc-updatemanager” is the TrueOS system update utility and an essential part of the install/update routines.


Q28: Hardware Blacklist
I do not believe TrueOS has any “hardware blacklist” file that we set/distribute (if there is one, it will be coming directly from upstream FreeBSD). If you find one that FreeBSD uses, we are always open to modifications/suggestions as appropriate.

Q29: gpg-agent

Q30: ISO Checksums
All of the checksums are located directly in the download directories, with entries in our “files.json” manifest for MD5 checksums, sha256 checksums, PGP signatures, and torrents for each image. The web team did not want to put all of those files into the download boxes on the website for fear of overloading the user, but perhaps we could expand the “Browse” option into a few variants for each of the various download directories. The reason for “master/” instead of “stable/” on the download site is historical, and changing it will cause a chain reaction of breakage that we simply did not want to cause (because so much of our workflow is automated).

STABLE Downloads
UNSTABLE Downloads


First of all we would like to say thank you for all the replies and especially to Mr. Moore. The answers given clarified a great deal of issues we had in mind.

However the following questions still need a little bit of clarification in our opinion. If you could help us with those we would greatly appreciate that! :slight_smile:

Q#1: There is no specific other reason for that package to be removed from TrueOS, but concerns of espionage done by intelligence organizations. We came to the conclusion that the removal and explicit activation of audio and video equipment does increase the level of security in computer systems.

Q#2: Thank you for removing HAL in the configuration, and for all the following changes made. Maybe for that alone our review may have been worth the effort.


Q#8: Yes. We realized just now, that pc-sysinstaller is a separate project on GitHub, besides several more ones we have not seen yet. Wow, you devs were busy as a bees! Thus we have to do a lot of reading…

Q#11: We realize that fact and also are aware of PC-BSD. However, we would like to understand the state of Lumina and Polkit (successor of Policykit), meaning what your future plans actually are, regarding that security-related aspect.

Q#12: Unfortunately such “lame” hacks have proven to be needed. On one instance employees of a European ISP liked to kill Xfce sessions of their colleagues, by pressing Ctrl + Alt + Backspace, and effectively killing GDM and Xfce plus all running programs. We consider that a local security hazard and would therefore like to see this remediated if possible.

Q#13: Would you please elaborate a bit on the idea behind PICO? Why not boot TrueOS in live mode (full image) and access TrueOS servers? Due to hardware constraints? Unfortunately our organizations policy prevents us from experimenting with micro hardware, such as Raspberry Pi.

Q#21: Thank you!

Q#22, Q#23, Q#28: Regarding that question research has to be done. Therefore we will come back later with suggestions.

Q#27: The sys-init script is only run the first time a system is booted after an installation RAM will not increase after a post-installation RAM upgrade, right? Do you have any idea how to handle such a post-install RAM upgrade?


I’m not answering for anyone on the project, but find some of these curious.
Q#27: ZFS ARC is filesystem cache used internally by the operating system. A system RAM upgrade without resetting the value simply means the ARC will not grow any larger. In the grand scheme of things, it’s basically a “who cares” situation. If I have a bazillion gigabytes of system RAM but set the max ARC growth to 2GB, it simply means I may have performance issues under certain use cases that would benefit from more RAM. Someone using TrueOS (really FreeBSD) that can upgrade system RAM most likely knows how to tune ZFS settings if they need to and if not they know how to do an internet search.

Or are you suggesting that not tuning ZFS ARC max to use more system RAM is somehow a security vulnerability?

Q#12: a person with physical access to a system can do havoc? I think that problem has been around since at least the abacus, no?


Correct. That is why we brought this issue to the attention of the TrueOS developers, no more and no less than that. We do not suggest we are competent enough here to make a final decision on whether that is an error that should be fixed or not (and if so in which part of the system). Our intention was to bring up our finding and ask the devs whether they regard that as a problem or not, and would like to correct it if so.

Yes, indeed. However one which is so well-known, so easily exploitable and so disruptive and annoying, that it should be fixed on production workstation systems by default, besides disabling Ctrl + Alt + Del, and the implementation of further hardening measures. Since TrueOS uses X11 and display mangers, we just wanted to bring the issue to the devs’ attention. The suggested fix should not be intrusive (we hope) and everyone would probably benefit from it.


@TRON-DELTA I truly appreciate the time, effort, and level of detail you have provided here. I have been working with @beanpole135, the rest of core on a tracking, and cleanup of old code effort which we had discussed previously. Your input has been very helpful towards this goal, and has been well needed. Thank you for this review. I look forward to more.


To answer your follow-up questions:

Q1 webcamd
Thanks you for clarifying that. Yes, we do build and pre-install the webcamd drivers on TrueOS systems, but if this is still a concern to you (even without HAL and the other integration daemons from Linux) it is possible to disable loading those drivers by simply turning off the “webcamd” service (rc-update delete webcamd default, and service webcamd stop).

We have had HAL and GVFS disabled in TrueOS for quite some time. We try to keep up on known security vulnerabilities and regularly disable/deactivate 3rd-party packages and/or integrations as needed to preserve the system security. This exact same focus is also why we disabled OpenSSL and only use LibreSSL for the base system and all packages.

Q8 Github Repositories
Yes, TrueOS tries to have a clear and logical organization for source control, and one of those methods is separate repositories (under the “TrueOS” umbrella organization) for each of the distinct tools/utilities. The “trueos-core” repository that you started with is actually the last holdover from the PC-BSD days and was next on the list for cleanup and distribution between other repositories (since PC-BSD had almost everything in a single repository).

Q11 PolicyKit
There are no integrations between TrueOS and PolicyKit (or PolKit), and no plans to ever support such integrations. Frameworks like that are antithetical to the nature of FreeBSD/TrueOS and ultimately are just lame hacks to work around basic security systems that are integrated at the OS level. For any authentication integrations the TrueOS utilities have always used PAM to communicate with the OS. This lets the OS do “the right thing” rather than trying to “bypass” basic authentication subsystems.

Q12 Ctrl-Alt-Backspace
This functionality is already disabled by default on installed systems. However, even if it is re-activated and triggered by the user this does not result in loss of your graphical session. PCDM (our self-written graphical login manager) behaves quite differently from it’s Linux counterparts and partially runs outside of the X11 session. This allows it to detect/restart the graphical login prompt on individual TTY’s if the X11 session is stopped for any reason.

The point behind PICO is to leverage the plethora of small hobbyist boards as fully-functional desktop systems without many of the complexities of building/distributing full package repositories for each of the distinct system architectures used (each board/device is different from the others). Our solution was a fully “thin-client” framework where a small/static install image is the only thing needed for the device itself and all the processing and capabilities are run on the standardized 64-bit system instead (so ZFS can be used for data integrity, disk performance, higher memory, etc). This is primarily targetted for deployments in such environments as computer labs or classrooms where a private, high-speed network is used to facilitate a multitude of access terminals through a single (typically more beefy) graphical system.

Yes, the sys-init script is only run once - during the first-boot procedure immediately after install. The ZFS tuning method is primarily to scale-down the reserved memory for ZFS to weaker hardware (or virtual environments). ZFS by default reserves a much higher amount of dedicated memory but that is uneeded for most desktop/server usage scenarios and is trivially “tuned down” to more reasonable levels by our script. For the particular use-cases where a user would benefit from a higher ZFS ARC (such as when you look at the FreeNAS project with large data management), then that option can be easily re-tuned to suit the user’s particular needs later.


Thank you, jmaloney for your nice words! We will do our best and continue our work.

beanpole135, we thank you as well for your input! We would yet like to know with regards to Q#11 (PolicyKit/PAM), whether you devs plan on adding to the PAM configuration file, like minimum password length or pam_ckracklib (if that available for BSD). Are there any such plans for the future?


We do not currently modify the PAM configuration for the system from the FreeBSD defaults, but we are not averse to doing so.

Our general rules for modifying FreeBSD’s default configration files out-of-box are:

  1. User-Transparent: If we can turn on a security setting without any side-effects for general user operations, then we go ahead and do it.
  2. User-Intrusive: If a security setting is considered essential for some systems but comes with significant drawbacks on basic user operations we will generally go with making it an optional system modification that can be toggled/run during the firstboot setup procedures. This allows people to “know what they are getting” rather than just foisting a (possibly significant) change upon them.


Quick follow up with the default PAM configuration out-of-box for FreeBSD:

The “pam_passwdqc” module (newer form of the old “pam_cracklib”) is already included out of box, but the default configuration (/etc/pam.d/passwd) has that one disabled and the standard “pam_unix” set as the default.

Contents of "/etc/pam.d/passwd "

# $FreeBSD$
# PAM configuration for the "passwd" service

# passwd(1) does not use the auth, account or session services.

# password
#password       requisite         enforce=users
password        required             no_warn try_first_pass nullok

I am open to switching that logic around by default, and even adding a couple extra options to the pam_passwdqc usage such as “retry=3” or basic min/max password length checking.


Thank you! We added that to our list of items to review, when commencing system audits with Lynis in the future.