IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
In some cases it's useful to explicitly generate the JSON field names to
generate for table columns, instead of auto-mangling them from table
header names that are intended for human consumption.
This adds the infra and a test for it.
It's intended to be used by #20544, for the first column, which in text
mode should have an empty header field, but have an explicit name in
json output mode.
With this change, "mkosi build" will automatically build systemd for the
current distro without any further configuration. If people want to do a
cross-distro build by default, they can still create mkosi.default, but I
assume that this is relatively rare.
If people have symlinked mkosi.default to one of the files in .mkosi/, they'll
need to adjust the symlink.
(Building without configuration would always fail, since systemd has many many
required dependencies. I think it's nicer to do the most commonly expected
thing by default, i.e. rebuild for the current distro.)
Mkosi is nowadays packaged for most distros, so recommend installing of distro
packages as the primary installation mechanism.
The pattern was added in 6242cda99d, with the
idea that users will have local configuration files for mkosi and git should
not bother them about those. But let's make this narrower, and only match
files with "local". This way we reduce the risk that some unrelated file
will be ignored by accident.
.gitignore in the parent directory is used, because mkosi apparently tries
to load all files under mkosi.default.d/, without looking at the extension.
This is probably something to fix in mkosi too.
The comments were outdated: at least "nfsnobody" is not used in Fedora since a
few years. So I hope we don't need this anymore. The meson build scripts do
autodetection on their own.
Procotol analyzers are external devices used to capture traffic over a
wire so that it could be analysed. End-users at the console should be
able to access those devices without requiring root access.
This change obsoletes the need to install Total Phase's "Linux drivers",
which are really just udev rules and hotplug usermap files to do that:
https://www.totalphase.com/products/usb-drivers-linux/
journal_file_verify() uses a set of tmpfs files to create lists
of object positions by type.
The existing code used a bare write() call for every object
position written, incurring a syscall per listed object.
This commit encapsulates the bare file descriptors in FILE *'s
and replaces the bare write with fwrite, buffering the writes so
there's less syscalls.
Cached `journalctl --verify` tests showed a ~8% faster runtime
with this change on a release build, verifying 1.3GiB of
production journals across 16 files.
Previously, the devlink was created based on the priority saved in udev
database. So, we needed to reevaluate devlinks after database is saved.
But now the priority is stored in the symlink under /run/udev/links, and
the loop of devlink creation is controlled with the timestamp of the
directory. So, the double evaluation is not necessary anymore.
By the previous commit, it is not necessary to distinguish if the devlink
already exists. Also, I cannot find any significant advantages of the
previous complecated logic, that is, first try to create directly, and then
fallback to atomically creation. Moreover, such logic increases the chance
of conflicts between multiple udev workers.
This makes devlinks always created atomically. Hopefully, this reduces the
conflicts between the workers.
During creating a symlink to a device node, if another device node which
requests the same symlink is added/removed, `stat_inode_unmodified()`
should always detects that. We do not need to continue the loop
unconditionally.
Previously, we only store device IDs in /run/udev/links, and when
creating/removing device node symlink, we create sd_device object
corresponds to the IDs and read device node and priority from the
object. That requires parsing uevent and udev database files.
This makes link_find_prioritized() get the most prioritzed device node
without parsing the files.
It expects a generic "struct sockaddr", not a "struct sockaddr_un".
Pass the right member of the union.
Not sure why gcc/llvm never complained about this...
When pulling in the SHA256 implementation from glibc, only some of the
coding style was adjusted to ours, other was not. Let's make things a
bit more consistent.
The GUIDs we usually deal with should be considered constant. Hence make
them so. Unfortunately the prototypes for various functions doesn't mark
them as const (but still decorates them with "IN", clarifying they are
input-only), hence we need to cast things at various places. We already
cast in similar fashion in many other cases, hence unify things here in
one style.
Making the EFI_GUID constant (and in particular so when specified in C99
compound literal style) allows compilers to merge multiple instances of
them.
The automatic logic can't always find the original root partition (ex:
if the rootfs is copied to a ext4 fs backed by zram in the initramfs),
so we want to support "/run/systemd/volatile-root" which is a symlink to
the original root partition.
Fix#20610
Import hwdb matches for USB devices (not interfaces) which don't usually
have a modalias so that it's possible to, for example, make them
available for unprivileged users.
As we usually do, remove old unix socket before bind.
Note that systemd-udevd-control.socket has `RemoveOnStop=yes`.
So, it is not necessary to be removed when the service exits.
Replaces #20584 and #20588.
This is a small cosmetic change.
Before:
Offered DHCP leases: 192.168.0.183 (to 0:9:a7:36:bc:89)
After:
Offered DHCP leases: 192.168.0.183 (to 00:09:a7:36:bc:89)
The 'security' verb of systemd-analyze needs to be able to parse JSON files to be able to read in
the user-defined requirements and use them to determine the overall exposure level of the specified unit
file(s). The JSON files are expected to have a specific format where the keys in the file are the
unit ids consisting of only alphanumeric characters and underscores and the values are JSON objects
again consisting of key value pairs. The keys in these objects may include one or more of the following
properties: description_na, description_good, description_bad, weight, and range. The first three of these
are expected to be strings and the latter two are expected to be unsigned integer values. If one or more
of these properties is missing from the JSON object, then the default values of the properties as specified
in the hard coded set of security directives is used. The other properties that assess() needs to determine
overall exposure levels for a unit file for example, the assess function and parameter type among others,
are not to be included in the JSON files defined by the user because the values assigned to these fields
are expected to be consistent across unit files for each id.
A new option --security-policy= is added to work with the 'security' verb in order to enable
users to create and pass in a JSON file consisting of user defined requirements
against which to compare the specified unit file(s). These requirements then serve
as the measure of security threats for the file instead of the initial hard coded set of
requirements that the 'security' verb of systemd-analyze relied on.
Example Run:
A snapshot of the user defined testfile.json file is shown below instead of the complete file
for readability purposes.
{
"PrivateDevices":
{"description_good": "Service has no access to hardware devices",
"description_bad": "Service potentially has access to hardware devices",
"weight": 1000,
"range": 1
},
"PrivateMounts":
{"description_good": "Service cannot install system mounts",
"description_bad": "Service may install system mounts",
"weight": 1000,
"range": 1
},
"PrivateNetwork":
{"description_good": "Service has no access to the host's network",
"description_bad": "Service has access to the host's network",
"weight": 2500,
"range": 1
},
"PrivateTmp":
{"description_good": "Service has no access to other software's temporary files",
"description_bad": "Service has access to other software's temporary files",
"weight": 1000,
"range": 1
},
"PrivateUsers":
{"description_good": "Service does not have access to other users",
"description_bad": "Service has access to other users",
"weight": 1000,
"range": 1
}
}
1. I created the jsontest.service file in order to test the --security-policy= option as follows:
maanya-goenka@debian:~/systemd (custom-security)$ cat<<EOF>jsontest.service
> [Service]
> ExecStart = echo hello
> PrivateNetwork = yes
> PrivateDevices = yes
> PrivateMounts = yes
> EOF
The security analysis table outputted below has been truncated to include only the first few lines for readability.
maanya-goenka@debian:~/systemd (custom-security)$ sudo build/systemd-analyze security --root= --offline=true
--security-policy=src/analyze/testfile.json jsontest.service
/usr/lib/systemd/system/plymouth-start.service:15: Unit configured to use KillMode=none. This is unsafe, as it disables systemd's
process lifecycle management for the service. Please update your service to use a safer KillMode=, such as 'mixed' or 'control-group'.
Support for KillMode=none is deprecated and will eventually be removed.
/usr/lib/systemd/system/gdm.service:30: Standard output type syslog is obsolete, automatically updating to journal. Please update your
unit file, and consider removing the setting altogether.
/usr/lib/systemd/system/dbus.socket:5: ListenStream= references a path below legacy directory /var/run/, updating
/var/run/dbus/system_bus_socket → /run/dbus/system_bus_socket; please update the unit file accordingly.
NAME DESCRIPTION
✓ PrivateNetwork Service has no access to the host's network
✗ UserOrDynamicUser Service runs as root user
✗ CapabilityBoundingSet_CAP_SET_UID_GID_PCAP Service may change UID/GID identities/capabilities
✓ PrivateMounts Service cannot install system mounts
✓ PrivateDevices Service has no access to hardware devices
→ Overall exposure level for jsontest.service: 8.3 EXPOSED 🙁
maanya-goenka@debian:~/systemd (custom-security)$ echo $? 0
2. In order to ensure that the JSON data was actually being correctly parsed, I made some changes to the JSON
file, specifically to the id "PrivateNetwork" as follows:
Before:
--------
"PrivateNetwork":
{"description_good": "Service has no access to the host's network",
"description_bad": "Service has access to the host's network",
"weight": 2500,
"range": 1
}
After:
--------
"PrivateNetwork":
{"description_good": "Service runs without access to host network",
"description_bad": "Service has access to the host's network",
"weight": 6000,
"range": 1
}
As expected, the new description for the description_good field of the Private Network id was updated in
the analysis table outputted below and the overall exposure level of the unit file decreased because
the weight assigned to 'Private Network' (which is set to yes) increased from 2500 to 6000.
maanya-goenka@debian:~/systemd (custom-security)$ sudo build/systemd-analyze security --root= --offline=true
--security-policy=src/analyze/testfile.json jsontest.service
/usr/lib/systemd/system/plymouth-start.service:15: Unit configured to use KillMode=none. This is unsafe, as it disables systemd's
process lifecycle management for the service. Please update your service to use a safer KillMode=, such as 'mixed' or 'control-group'.
Support for KillMode=none is deprecated and will eventually be removed.
/usr/lib/systemd/system/gdm.service:30: Standard output type syslog is obsolete, automatically updating to journal. Please update your
unit file, and consider removing the setting altogether.
/usr/lib/systemd/system/dbus.socket:5: ListenStream= references a path below legacy directory /var/run/, updating
/var/run/dbus/system_bus_socket → /run/dbus/system_bus_socket; please update the unit file accordingly.
NAME DESCRIPTION
✓ PrivateNetwork Service runs without access to the host's network
✗ UserOrDynamicUser Service runs as root user
✗ CapabilityBoundingSet_CAP_SET_UID_GID_PCAP Service may change UID/GID identities/capabilities
✓ PrivateMounts Service cannot install system mounts
✓ PrivateDevices Service has no access to hardware devices
→ Overall exposure level for jsontest.service: 7.8 EXPOSED 🙁
maanya-goenka@debian:~/systemd (custom-security)$ echo $? 0
3. When paired with security's --threshold= option, systemd-analyze exits with a non-zero error status indicating
that the overall exposure level for the unit file (=78) is greater than the set threshold (=70). The same
jsontest.service file is used for the demo run below:
maanya-goenka@debian:~/systemd (custom-security)$ sudo build/systemd-analyze security --root= --offline=true
--security-policy=src/analyze/testfile.json --threshold=70 jsontest.service
/usr/lib/systemd/system/plymouth-start.service:15: Unit configured to use KillMode=none. This is unsafe, as it disables systemd's
process lifecycle management for the service. Please update your service to use a safer KillMode=, such as 'mixed' or 'control-group'.
Support for KillMode=none is deprecated and will eventually be removed.
/usr/lib/systemd/system/gdm.service:30: Standard output type syslog is obsolete, automatically updating to journal. Please update your
unit file, and consider removing the setting altogether.
/usr/lib/systemd/system/dbus.socket:5: ListenStream= references a path below legacy directory /var/run/, updating
/var/run/dbus/system_bus_socket → /run/dbus/system_bus_socket; please update the unit file accordingly.
NAME DESCRIPTION
✓ PrivateNetwork Service runs without access to host network
✗ UserOrDynamicUser Service runs as root user
✗ CapabilityBoundingSet_CAP_SET_UID_GID_PCAP Service may change UID/GID identities/capabilities
✓ PrivateMounts Service cannot install system mounts
✓ PrivateDevices Service has no access to hardware devices
→ Overall exposure level for jsontest.service: 7.8 EXPOSED 🙁
maanya-goenka@debian:~/systemd (custom-security)$ echo $? 1
new option
