Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Small systemd hardening #171

Closed
wants to merge 1 commit into from
Closed

Small systemd hardening #171

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
6 changes: 6 additions & 0 deletions lib/systemd/system.conf.d/30_security-misc.conf
View file
Open in desktop
@@ -0,0 +1,6 @@
[Manager]
DumpCore=no
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. This can also be set by kernel command line. Better to set by config or append the already super long kernel command line?

  2. Please add a link to the related systemd documentation.

  3. Please add to readme.

  4. Please undo in debug-misc package and add to readme there.

These are all the steps that I would have to do otherwise. I might some day but could be considerably delayed until I get to that.

## Allow no non-native calls as these may be used to circumvent some security protections
## For example 32 bit x86 code is executable in modern 64 bit x86 systems because of backwards
## compatibility. This is undesirable and can potentially be dangerous.
SystemCallArchitectures=native
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems high potential for breakage. Do I have specific examples? No. But I have an approach for such situations...

Could you please suggest changing the default upstream at systemd instead? That would probably result in valuable insights if this is useful, why it's not the upstream default and/or what breakage to expect.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems high potential for breakage. Do I have specific examples? No. But I have an approach for such situations...

Very big no. On a daily basis, you would rarely ever execute something of another architecture. For the most part, you can't anyway. For some, like 32 bit x86, you can do it because of backwards compatibility. But there aren't 32 bit x86 binaries on your 64 bit system anyway. This does not happen normally. x86 64 bit has been the industry standard for more than 20 years. Now, almost no operating system, even including the various linux distros, supports the 32 bit architecture, let alone the invidiual pieces of software. It bring no benefit to be able to execute those.

Other than that, there aren't any other use cases of supporting non native architectures, far as I know.

To be honest, since this never ever occurs, it also brings not too much extra security, because you won't make non native calls anyway. But it also brings no harm, IMO.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok. Please add to readme too.