Hi,
CAP_SYS_ADMIN: exceed /proc/sys/fs/file-max
Quick note: you can change that particular limit via the systemd
.service file (LimitNOFILE= – see "man systemd.exec").
rsyslog thus doesn't need that cap.
Also, on my mostly-vanilla system,
$ ulimit -n -H
1048576
$
I hesitate to speculate
Hi,
I appreciate all the excellent feedback so far.
Thanks a lot!
Fwiw, the current set of hardening features in rsyslog.service is
available at
https://salsa.debian.org/debian/rsyslog/-/blob/debian/master/debian/rsyslog.service#L18
I will see, if I can incorporate some of the suggestions by
Hi,
On 10/17/23 01:24, Michael Prokop wrote:
# Restrict access to the various process namespace types the Linux kernel
provides
RestrictNamespaces=true
There is one plugin that uses namespaces. I wonder if it would make
sense to split it out into a separate package, and have that
* Michael Biebl [Wed Oct 11, 2023 at 12:14:47PM +0200]:
> Am 11.10.23 um 08:03 schrieb Simon Richter:
> > On 10/11/23 03:22, Michael Biebl wrote:
> >
> > > I intend to lock down rsyslog.service in Debian in one of the next
> > > uploads using the following systemd directives
> >
> > >
* Michael Biebl [Tue Oct 10, 2023 at 08:22:26PM +0200]:
> I intend to lock down rsyslog.service in Debian in one of the next
> uploads using the following systemd directives
That's great to hear, thanks for working on this.
> PrivateTmp=yes
>
Michael Biebl wrote:
> - CAP_SYS_ADMIN: exceed /proc/sys/fs/file-max, the system-wide limit
> on the number of open files, in system calls that open files (e.g.
> accept execve), use of setns(),...
I realize that you can't lock down things upstream still requires, but
CAP_SYS_ADMIN is
Am 11.10.23 um 23:48 schrieb Robert Edmonds:
Michael Biebl wrote:
While the attempt is to secure the default configuration of rsyslog, I
do not want to restrict it so much that it becomes unusable.
If you think, that one of those directives could cause issues with
commonly used setups, please
Michael Biebl wrote:
> While the attempt is to secure the default configuration of rsyslog, I
> do not want to restrict it so much that it becomes unusable.
> If you think, that one of those directives could cause issues with
> commonly used setups, please let me know, so I can adjust the
>
Am 11.10.23 um 13:41 schrieb Michael Biebl:
Am 11.10.23 um 12:54 schrieb Sam Morris:
On 10/10/2023 19:22, Michael Biebl wrote:
I intend to lock down rsyslog.service in Debian in one of the next
uploads using the following systemd directives
Have you considered NoNewPrivileges=yes?
This is
Am 11.10.23 um 12:54 schrieb Sam Morris:
On 10/10/2023 19:22, Michael Biebl wrote:
I intend to lock down rsyslog.service in Debian in one of the next
uploads using the following systemd directives
Have you considered NoNewPrivileges=yes?
This is turned in implicitly by some of the other
On 10/10/2023 19:22, Michael Biebl wrote:
I intend to lock down rsyslog.service in Debian in one of the next
uploads using the following systemd directives
Have you considered NoNewPrivileges=yes?
This is turned in implicitly by some of the other options (e.g,.
PrivateDevices=yes) but only
Hi,
On 10/11/23 19:14, Michael Biebl wrote:
- CAP_NET_ADMIN: use of setsockopt()
- CAP_SYS_ADMIN: exceed /proc/sys/fs/file-max, the system-wide limit on
the number of open files, in system calls that open files (e.g. accept
execve), use of setns(),...
I see, thanks!
I looked over the code
Am 11.10.23 um 08:03 schrieb Simon Richter:
Hi,
On 10/11/23 03:22, Michael Biebl wrote:
I intend to lock down rsyslog.service in Debian in one of the next
uploads using the following systemd directives
CapabilityBoundingSet=CAP_BLOCK_SUSPEND CAP_CHOWN CAP_LEASE
CAP_NET_ADMIN
Hi,
On 10/11/23 03:22, Michael Biebl wrote:
I intend to lock down rsyslog.service in Debian in one of the next
uploads using the following systemd directives
CapabilityBoundingSet=CAP_BLOCK_SUSPEND CAP_CHOWN CAP_LEASE
CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_SYS_ADMIN CAP_SYS_RESOURCE
14 matches
Mail list logo
