-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Security Manager Replacement] Strengthen OS core security via systemd configuration #16729
Comments
A list of configs to be amended to exiting config
|
// todo explore below configs
|
nice to see this work here, especially sandboxing things such as filesystem with systemd fills a big gap that security manager was doing, and IMO does it in a much better way. I'd be curious to see change in reported exposure level from |
thanks @rmuir. I will post the results from |
cc @andrross |
Thanks @kumargu, I think this approach is super promising. It does raise some questions around testing and maintaining a properly secured systemd config. We'll need to evaluate our integration testing and release pipeline to ensure we have proper coverage of this, as the evolving code base may sometimes (rarely I hope) require tweaks to this config. |
You don't need to have all the i'd nuke all the Same goes with your |
Ack @rmuir, I'll make changes as suggested by you, all your comments makes sense to me. I am going to try out the actual integration tomorrow and post results. (edit) 3/12/24 Updated the initially proposed configs based on rmuir@ comments. Haven't yet changed the |
@andrross -- thanks for bringing up the testing part of it. I will think more about it. At the moment, I could think of having a I don't think we will be able to get a full coverage, but we can cover for the most critical ones. And yes, it would be rare we'd be changing the configs. |
Adding the output of Before(represents the systemd config currently shipped with 2.18)
After(systemd configs edited as per comment to add restrictive policies)
|
@kumargu That's one aspect of the testing. That other side is ensuring that the OpenSearch software doesn't need access to something that the systemd config restricts. I'm not sure where in our testing pipeline we ever launch the OpenSearch process with systemd. An extreme example: you could block port 9200 in the systemd config and I think |
yes, you need to test systemd service works (using vm or container). But lack of testing for the systemd service is nothing new with this issue, it is a pre-existing condition as there is already a systemd service being shipped, just with an EXPOSED configuration. |
and the change will come anyway, probably via distros if you dont do it yourself (e.g. https://fedoraproject.org/wiki/Changes/SystemdSecurityHardening). Distros will probably just let end-users be the testers, so you might as well get ahead of it |
we actually used to have full fledged disto tests (see please [1]), driven by VMs and vagrant, but I am not sure it is in a good shape now, it has not been run for a looong time [1] #538 |
yeah, if you just want to test systemd service unit, you can use container for that (you have to hold it special: happy to help as i do this at dayjob). If all you are shipping is a service file, that's enough. Perversely, you have to give systemd container special privileges otherwise it can't actually implement the very sandboxing you wish to test, so you have to supply some special docker flags. See https://systemd.io/CONTAINER_INTERFACE/#what-you-shouldnt-do for some background. if you are also shipping packages (such as RPM, DEB, etc), you can still use same approach, to also check that package and its dependencies install/remove/upgrade correctly, too, all within container. So it gets you pretty far, from upstream project perspective I think its the way to go. VM is a bit extreme: of course you need it if you want to also test full integration with shenanigans of distro kernel, since container cannot do that: but it makes life so unfriendly to developers and CI systems that you end out with tests not being run at all or not being maintained like #538 |
Here's example ---
services:
# self-contained systemd example: run 'docker-compose up' to see it
amazonlinux:
build:
dockerfile_inline: |
FROM amazonlinux:2023
# install systemd
RUN dnf -y install systemd && dnf clean all
# in practice, you'd COPY in the RPM you want to test right here
RUN dnf -y install https://artifacts.opensearch.org/releases/bundle/opensearch/2.18.0/opensearch-2.18.0-linux-x64.rpm && dnf clean all
# no colors
ENV SYSTEMD_COLORS=0
# no escapes
ENV SYSTEMD_URLIFY=0
# explicitly specify docker virtualization
ENV container=docker
# for debugging systemd issues in container, you want this, but it is very loud!
# ENV SYSTEMD_LOG_LEVEL=debug
# plumb journald logs to stdout
COPY <<EOF /etc/systemd/journald.conf
[Journal]
ForwardToConsole=yes
EOF
# start systemd as PID 1
CMD ["/sbin/init"]
# enable opensearch service
RUN systemctl enable opensearch
# shutdown systemd properly
STOPSIGNAL SIGRTMIN+3
# disable security plugin, as i don't configure SSL (but could be done with openssl or whatever right here)
RUN echo "plugins.security.disabled: true" >> /etc/opensearch/opensearch.yml
# provide /dev/console for journal logs to go to stdout
tty: true
# capabilities to allow systemd to sandbox
cap_add:
# https://systemd.io/CONTAINER_INTERFACE/#what-you-shouldnt-do bullet 1
- SYS_ADMIN
# https://systemd.io/CONTAINER_INTERFACE/#what-you-shouldnt-do bullet 2
- MKNOD
# evil, but best you can do on docker? podman is better here.
cgroup: host
volumes:
- /sys/fs/cgroup:/sys/fs/cgroup
# tmpfs mounts for systemd
tmpfs:
- /run
- /run/lock
# health check for opensearch
healthcheck:
test: ["CMD", "curl", "-f", "http://127.0.0.1:9200/_cluster/health"] |
And here's what the output looks like on
|
Thanks for the pointers. I am going to try it the full integration today. |
Yeah, it helps to test it. you can already see small problems with the systemd unit. For example it logs with tag I would set |
agreed. will address it. |
sorry for the delay, I will come back to this in a week. |
[Catch All Triage - 1, 2, 3] |
Please describe the end goal of this project
The OS core's security in absence of security manager can be strengthened by using a stronger systemd unit configuration. We can imagine this as sandboxing via
systemd
protecting itself from vulnerability in core or untrusted code (plugins). However, this is not a complete replacement of security manager, a part of it like controlling access to egress network, controlling access to specific file locations can be sought as a replacement. Some of the newly introduced configs will add more security than what is being offered by security manager.Supporting References
#1687
Issues
#16634
Related component
Other
The text was updated successfully, but these errors were encountered: