HardenedBSD issueshttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues2022-03-15T16:27:28Zhttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/71Deorbit Intel SGX support2022-03-15T16:27:28ZShawn WebbDeorbit Intel SGX supportIntel is deprecating SGX support in 11th and 12th gen CPUs. And for good reason.Intel is deprecating SGX support in 11th and 12th gen CPUs. And for good reason.LoicLoichttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/57hbsd-update: Provide a "download only" option2021-07-10T18:55:45ZShawn Webbhbsd-update: Provide a "download only" optionMake it easy to simply download the update archive and not do anything with it, not even extracting it. This will enable a user to be able to inspect the archive and manually apply parts of it if needed.Make it easy to simply download the update archive and not do anything with it, not even extracting it. This will enable a user to be able to inspect the archive and manually apply parts of it if needed.LoicLoichttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/50Improve EFI framebuffer startup2022-02-03T19:45:19ZLoicImprove EFI framebuffer startupThe EFI framebuffer boot in FreeBSD (so HardenedBSD) often crashes on modern computers:
![20210517_162746](/uploads/2ed672f6d1d13403b2076d9a6bb109bf/20210517_162746.jpg)
See: [Bug 255208](https://bugs.freebsd.org/bugzilla/show_bug.cgi?i...The EFI framebuffer boot in FreeBSD (so HardenedBSD) often crashes on modern computers:
![20210517_162746](/uploads/2ed672f6d1d13403b2076d9a6bb109bf/20210517_162746.jpg)
See: [Bug 255208](https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209821#c35)
OpenBSD does not have this problem, we should see if we can borrow a solution.LoicLoichttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/47Disable INCLUDE_CONFIG_FILE2023-01-31T13:57:59ZShawn WebbDisable INCLUDE_CONFIG_FILEIn our quest to remove "kernel infoleaks as features", we should disable the `INCLUDE_CONFIG_FILE` kernel config option. Doing this has a negative impact in kernel crash dump analysis, but helps with our overall goal of removing kernel i...In our quest to remove "kernel infoleaks as features", we should disable the `INCLUDE_CONFIG_FILE` kernel config option. Doing this has a negative impact in kernel crash dump analysis, but helps with our overall goal of removing kernel infoleaks.LoicLoichttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/45Create bootloader branding2021-05-28T18:42:49ZShawn WebbCreate bootloader brandingFreeBSD drastically updated the capabilities of the UEFI bootloader to support a framebuffer ( https://reviews.freebsd.org/D27420 ), enabling use of PNG files in the bootloader. We can now use high-resolution images to brand the bootload...FreeBSD drastically updated the capabilities of the UEFI bootloader to support a framebuffer ( https://reviews.freebsd.org/D27420 ), enabling use of PNG files in the bootloader. We can now use high-resolution images to brand the bootloader. This issue is to track the creation of said branding.LoicLoichttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/40Kernel panic with Intel Wireless 4965AGN chip2021-04-28T14:05:48ZRadosław ChmielarzKernel panic with Intel Wireless 4965AGN chipHi,
I hope this issue is directed at the correct project. In case I should contact FreeBSD please tell me so.
The issue was spotted when using OPNSense 21.1.4, which is using FreeBSD 12.1-RELEASE-p15-HBSD.
After attaching Intel Wirele...Hi,
I hope this issue is directed at the correct project. In case I should contact FreeBSD please tell me so.
The issue was spotted when using OPNSense 21.1.4, which is using FreeBSD 12.1-RELEASE-p15-HBSD.
After attaching Intel Wireless WiFi Link 4965AGN I have experienced a kernel panic with stack trace pointing to ieee80211_chan_init() originating from iwn_attach(). Probably the kernel is pointing to a more precise piece of code but I'm using an USB keyboard and the driver is probably not loaded at this point as I can't type anything.
I've made a low-tech picture with my phone.
![IMG_20210422_105743](/uploads/07165b23a091e181825d7cb5b80f2340/IMG_20210422_105743.jpg)
Cheers,
Radekhttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/39Update OpenSSH in base2021-09-15T18:15:34ZShawn WebbUpdate OpenSSH in baseThe version of OpenSSH in base is pathetically outdated with multiple known vulnerabilities. FreeBSD has fallen behind, so we need to do our own due diligence in keeping OpenSSH up-to-date in base. I'm marking this issue as "help wanted"...The version of OpenSSH in base is pathetically outdated with multiple known vulnerabilities. FreeBSD has fallen behind, so we need to do our own due diligence in keeping OpenSSH up-to-date in base. I'm marking this issue as "help wanted" because that's the reality.
This will be a longer task with the potential to be a continuous one.https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/34HardenedBSD installer shows security option for random pids2021-04-28T19:21:15ZSylvie RinnerHardenedBSD installer shows security option for random pidsIf you choose the randompid option in the installer, you will get an error from sysctl on boot because that setting is readonly in HardenedBSD. The solution is to hide that option in the installer altogether.If you choose the randompid option in the installer, you will get an error from sysctl on boot because that setting is readonly in HardenedBSD. The solution is to hide that option in the installer altogether.https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/24USB wireless mice are dead and frozen2023-09-19T00:01:40ZShawn WebbUSB wireless mice are dead and frozen*Created by: hd_scania*
Told to you on Telegram, with everyting, even **including** wireless networks, are still ok by having run XFCE by `startx`, but the USB **wireless** mice are still being dead, USB **wired** mice are **neither** w...*Created by: hd_scania*
Told to you on Telegram, with everyting, even **including** wireless networks, are still ok by having run XFCE by `startx`, but the USB **wireless** mice are still being dead, USB **wired** mice are **neither** working ...
My `rc.conf` has `moused_enable=YES` and `moused_type=auto`, but my USB wireless mice aren’t working yet ...
Plus by this turn backing to HBSD, SDDM is crashed, and Plasma is also still being turbulent ...
```
HardenedBSD 13-CURRENT
Host: Sony VPCCB17FG
Cores: Intel i7-2620M
RAM: 7.45GiB
Graphics: AMD Radeon
HardenedBSD root: 37.5GiB
SSD: 953GiB
```https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/22debugging using dtrace doesn’t appear to be working on HBSD 12.x2023-09-19T00:01:39ZShawn Webbdebugging using dtrace doesn’t appear to be working on HBSD 12.x*Created by: tuto2*
**Describe the bug**
When trying to use dtrace to monitor the kernel call stack, none of the kernel function names can be resolved by dtrace (and possibly other tools as well). Trying the same procedure on a stock Fr...*Created by: tuto2*
**Describe the bug**
When trying to use dtrace to monitor the kernel call stack, none of the kernel function names can be resolved by dtrace (and possibly other tools as well). Trying the same procedure on a stock FreeBSD machine does seem to function without issues.
When debugging the kernel source, we ran into this commit https://github.com/HardenedBSD/hardenedBSD/commit/37a8b2de291f4cb84b5cac86aab8e5edcaa75176 which describes the addition of a new privilege named `PRIV_KLD_STAT`, which, in the context of dynamically loaded kernel modules, is meant to prevent non-root users from being able to see kernel modules. This is indeed the case, except the root user get shielded from gaining insights into the machine as well due to masking the addresses in the same function (https://github.com/HardenedBSD/hardenedBSD/commit/37a8b2de291f4cb84b5cac86aab8e5edcaa75176#diff-c3d5aa900131c65102c23e944303538392a83cc73492e590a65b65f1b1505da1R1259-R1263).
One of the fastest pointers to tell something is off seems to be to to run `kldstat` as root and witness all kernel addresses are zeroed out (0x0). This becomes problematic when tracing kernel performance using Dtrace or any other facility, as C type data (ctf(5)) does not get resolved properly, and instead gets resolved to non-descriptive kernel addresses.
**To Reproduce**
The following steps assume the following options in GENERIC:
```
makeoptions DEBUG=-g
makeoptions WITH_CTF=1
options KDTRACE_FRAME
options KDTRACE_HOOKS
```
1. Build a DEBUG SMP kernel with `nooptions PAX_HARDENING` and run the following (arbitrary) command:
`dtrace -n uiomove:entry’{@[stack] = count(); }’`
Run this for some time and press CTRL-C. The result will show an aggregate of unique kernel stack traces, e.g.:
```
kernel`m_uiotombuf+0x10c
kernel`sosend_generic+0x40d
kernel`sosend+0x50
kernel`kern_sendit+0x237
kernel`sendit+0x19e
kernel`sys_sendto+0x4d
kernel`amd64_syscall+0x364
kernel`0xffffffff811e38d0
4
kernel`ttydisc_write+0xcc
kernel`ttydev_write+0x155
kernel`devfs_write_f+0xda
kernel`dofilewrite+0xb0
kernel`sys_write+0xc1
kernel`amd64_syscall+0x364
kernel`0xffffffff811e38d0
5
```
2. Do the same as step 1, but build the kernel with `options PAX_HARDENING`. The results are as follows:
```
0xffffffff80da98bc
0xffffffff80db29dd
0xffffffff80db2ed0
0xffffffff80db9d47
0xffffffff80dba0be
0xffffffff80db9f0d
0xffffffff8120b064
0xffffffff811e3b00
4
0xffffffff80da20fc
0xffffffff80d9c8b5
0xffffffff80ba777a
0xffffffff80d82b70
0xffffffff80d826d1
0xffffffff8120b064
0xffffffff811e3b00
5
```
**Expected behavior**
The question probably is if we really want to mask these addresses for the root user, there might be a use case for it, but if there is, it should be properly documented and perhaps being a separate build option so you don’t have to disable the PAX_HARDENING in full to stop masking addresses. If we assume that the root user itself was already properly safeguarded, question is why addresses are being masked since regular users seem not to be able to reach this point at all.
**Additional context**
The documentation at https://git-01.md.hardenedbsd.org/HardenedBSD/HardenedBSD/wiki#user-content-generic-system-hardening specifies that the PAX_HARDENING kernel option restricts what NON-root users are permitted to do. However, this option also affects the root user.
**Environment**
OPNsense 21.1.a (amd64, OpenSSL).https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/9Support filesystem extended attributes in tmpfs2023-09-19T00:01:32ZShawn WebbSupport filesystem extended attributes in tmpfsWe use filesystem extended attributes to toggle exploit mitigations. Poudriere uses tmpfs when building packages. In order to support the integration of HardenedBSD's exploit mitigation toggling with the ports tree, extended attribute su...We use filesystem extended attributes to toggle exploit mitigations. Poudriere uses tmpfs when building packages. In order to support the integration of HardenedBSD's exploit mitigation toggling with the ports tree, extended attribute support needs to be added to tmpfs.Shawn WebbShawn Webbhttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/6Port paxtest to kyua tests2023-12-01T15:36:37ZShawn WebbPort paxtest to kyua testsNow that FreeBSD imported kyua into base, porting `paxtest` from the tools repo to Kyua would be great. We could more easily track potential regressions. Additionally, we can get rid of the `paxtest` source tarball in the tools repo.
`p...Now that FreeBSD imported kyua into base, porting `paxtest` from the tools repo to Kyua would be great. We could more easily track potential regressions. Additionally, we can get rid of the `paxtest` source tarball in the tools repo.
`paxtest` lives here: https://git-01.md.hardenedbsd.org/HardenedBSD/tools/src/branch/master/tests/paxtest-freebsd/paxtest-0.9.14-freebsd.tgz