[continued from previous message]
access, filesystem mounting permissions, sysvipc, …) by default.
Additional
configuration allows inheritance of the IPs of the parent, sysvipc, memory page
locking, and use of the bhyve virtual machine monitor (vmm(4)).
Since the last report several ports have been modified to come with a service
jail config. Out of about 1460 start scripts in the ports collection, about 80
start scripts are changed. Prominent examples out of those are postgresql, DNS
servers, FTP servers, PHP, dovecot, postfix, rspamd, amavisd-new and clamav.
Some more changes are waiting for a treatment by the corresponding port
maintainers.
Any help in changing more start scripts (most of the time just one line to add)
is welcome. If you want to help, you can check the bugtracker link above for
changes which are already under review.
━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━
Userspace UFS Driver (fuse-ufs)
Links
fuse-ufs GitHub URL: https://github.com/realchonk/fuse-ufs
Contact: Benjamin Stürz
During this year’s Summer of Code, I wrote a userspace UFS driver using FUSE
and Rust. The project was meant to ease the process of mounting FreeBSD UFS
filesystems on other operating systems. Up to this point, only read-only
filesystem access has been implemented. But as a bonus, fuse-ufs has the
ability to mount filesystems with endianness different from the host’s
endianness.
I am currently working on splitting the project into a binary and library part,
to make it easier to integrate it into other operating systems. As part of this
refactoring, an additional FUSE2 backend will be implemented, to be able to run
it on OpenBSD. Currently there is testing infrastructure for Linux and FreeBSD
with OpenBSD coming in the future. Although there is no CI for MacOS, a friend
of mine tested it with MacFUSE and it works.
Once the big refactor is done, I will start concentrating on implementing write
support. Thanks to being bribed by Robert Clausecker, I will also add
soft-updates and mounting Sun’s UFS in the future.
The driver can be installed using cargo install fuse-ufs, or (if on Arch Linux)
using your favorite AUR helper. Thanks to Robert Clausecker a port for FreeBSD
exists in sysutils/fusefs-ufs.
A big thanks to Alan Somers and Kirk McKusick for mentoring me and thanks to
Robert Clausecker for the FreeBSD port and suggesting this GSoC project to me
in the first place. Another thanks to Davids Paskevics for writing a fuzzer for
me.
Sponsor: Google Summer of Code 2024
━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━
Kernel
Updates to kernel subsystems/features, driver support, filesystems, and more.
FreeBSD V4L2 & kernel USB Video Class driver
Links:
Public development repository URL: https://github.com/AlvinChen1
28/freebsd-src/tree/feature-uvc
Upstreaming preparation repository URL: https://github.com/lwhsu
freebsd-src/pull/2
Contact: Alvin Chen
Contact: Li-Wen Hsu
This work is to create FreeBSD UVC (USB Video Class) kernel driver and follow
v4l2 APIs, so that most of the Linux camera applications can be easily ported
to FreeBSD.
The code is still cleaning up and will be submitted to official review after
completing.
Current Status:
1. The key functions of the UVC driver are enabled.
2. The key v4l2 IOCTLs are implemented.
3. Support most of USB cameras (up to 4K resolution): Jabra, Logitech, etc.
4. Some applications validated: VLC, Cheese, pwcview.
Future Work:
1. A couple of v4l2 IOCTLs need be implemented: make all cases in
v4l2-compliance test suite be passed.
2. Some UVC APIs need be implemented: uvc control mapping callbacks, etc.
3. UVC lock issue related to USB.
4. PCI based AI camera supporting.
5. Code refactoring if needed.
Sponsor: Dell Technologies for the development
Sponsor: The FreeBSD Foundation for assistance of upstreaming
━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━
mac_do(4), setcred(2), mdo(1)
Contact: Olivier Certner Contact:
Baptiste Daroussin
This project aims at allowing controlled process credentials transitions
without using setuid executables but instead leveraging our MAC framework.
Traditional programs for credentials change have to execute preliminary
operations as root (if not as the effective UID, at a minimum as the saved
UID). Some of these programs (e.g., sudo(8)) have lots of lines of codes and
comprise features (e.g., loadable security modules) that can be dangerous from
a security standpoint. Thus, they have a non-negligible attack surface and are
difficult to prove correct. Additionally, in most scenarios, the extra features
they bring are not necessary.
More generally, the threat model for the mac_do(4) kernel module part is that
of compromised userland programs, be they credentials changers or credentials
providers ones. This stance implies that calls to the kernel’s
credentials-changing API must be monitored by the kernel without upcalls to
userland. In practice, mac_do(4) must be configured beforehand by the
administrator to indicate which transitions of credentials are valid (through a
sysctl(8) knob, security.mac.do.rules).
Currently, the companion userland program, mdo(1), is the only one that can be
authorized to proceed by mac_do(4) (for now, based on the executable path).
This tiny program simply establishes the new credentials via calls to setuid(2)
, and optionally initgroups(3) (calling setgroups(2)) and setgid(2) (if -i was
not passed).
The resulting set of groups is either that of the target UID based on the
password database, or that before the change in UID (when using -i). The second
alternative can be a security hazard in some cases (as the effective GID is not
changed either), whereas the first contradicts the threat model above. The
current mac_do(4) rules specification indeed only allows to express simple UID
transitions towards explicit UIDs from other explicit UIDs or GIDs, without
taking into account groups. Consequently, the kernel module currently cannot
check the content of setgroups(2) and setgid(2) system calls' parameters,
relying completely on mdo(1) passing the right information.
A new version of mac_do(4) has been in the works for approximately a month.
Besides fixing concurrency, per-jail settings and MAC policies composition
problems, it features a revamp of the rules specification in order to make it
possible to finely control which groups are allowed in the resulting
credentials. Notably, primary and secondary groups can now be specified
independently, and for the latter, GIDs can be tagged as allowed, mandatory or
forbidden. A special alias, ., can be used to indicate the current process'
UIDs or GIDs depending on the context.
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
