Hi,
* Colin Watson [2023-07-14 11:50]:
On Fri, Jul 14, 2023 at 08:08:39AM +0100, Matthew Garrett wrote:
On Thu, Jul 13, 2023 at 08:03:39PM +0200, Timo Röhling wrote:
> qemu is basically an interpreter for foreign machine code. If your
> threat model allows access to qemu-user-static for an
On Fri, Jul 14, 2023 at 08:08:39AM +0100, Matthew Garrett wrote:
> On Thu, Jul 13, 2023 at 08:03:39PM +0200, Timo Röhling wrote:
> > qemu is basically an interpreter for foreign machine code. If your
> > threat model allows access to qemu-user-static for an attacker, they
> > can run pretty much
On Thu, Jul 13, 2023 at 08:03:39PM +0200, Timo Röhling wrote:
> qemu is basically an interpreter for foreign machine code. If your
> threat model allows access to qemu-user-static for an attacker, they
> can run pretty much any binary is if it were native, and the whole
> SystemCallArchitectures
* Guillem Jover [2023-07-13 19:36]:
The same would apply to any other interpreted program, as long as the
interpreter matches the systemd native architecture.
This, by the way, includes the following scenario:
* Trent W. Buck [2023-07-06 10:41]:
dpkg --add-architecture arm64
apt
Hi!
On Thu, 2023-07-06 at 18:41:38 +1000, Trent W. Buck wrote:
> "Trent W. Buck" writes:
> > e.g. I expect "SystemCallArchitectures=native" to break for a lot of
> > people (anyone doing dpkg --add-architecture)
Yes, see #982456.
> Short version:
>
> • SystemCallArchitectures=native +
On Sun, 2023-07-09 at 18:02 +0100, Luca Boccassi wrote:
> Note that we already have such a package in the archive: dbus-broker.
> It has been the default in Fedora for a long time, and it will be the
> default in Ubuntu in the future. It has been available in Debian since
> Bullseye - please help
On Thu, 6 Jul 2023 at 09:42, Trent W. Buck wrote:
>
> "Trent W. Buck" writes:
> > e.g. I expect "SystemCallArchitectures=native" to break for a lot of
> > people (anyone doing dpkg --add-architecture)
>
> Short version:
>
> • SystemCallArchitectures=native + debianutils:i386 doesn't break
>
On Tue, 4 Jul 2023 at 09:28, Josh Triplett wrote:
>
> Simon McVittie wrote:
> > For example, dbus-daemon can only usefully have hardening applied if it
> > was built with traditional (non-systemd) service activation disabled,
> > which we cannot usefully do in Debian for two reasons: because we
"Trent W. Buck" writes:
> e.g. I expect "SystemCallArchitectures=native" to break for a lot of
> people (anyone doing dpkg --add-architecture)
Short version:
• SystemCallArchitectures=native + debianutils:i386 doesn't break
dpkg-db-backup.service.
• Probably savelog simply never calls an
Russ Allbery writes:
> "Trent W. Buck" writes:
>
>> As someone who does that kind of thing a lot, I'd rather have
>> the increased annoyance of opt-out hardening than
>> the reduced security of opt-in hardening.
>> Even if it means I occasionally need to patch site-local rules into
>>
"Trent W. Buck" writes:
> As someone who does that kind of thing a lot, I'd rather have
> the increased annoyance of opt-out hardening than
> the reduced security of opt-in hardening.
> Even if it means I occasionally need to patch site-local rules into
> /etc/apparmor.d/local/usr.bin.msmtp or
>
Russ Allbery writes:
> [⋯]
> We know which PAM modules are installed and
> can analyze the PAM configuration files to know which ones are configured.
> We know which daemons use PAM.
> We similarly know which NSS modules are enabled.
> We can figure out what facilities they require, and could
>
Philipp Kern writes:
> On 2023-07-05 09:36, Russell Coker wrote:
>> On Monday, 3 July 2023 22:37:35 AEST Russell Coker wrote:
>>> https://wiki.debian.org/ReleaseGoals/SystemdAnalyzeSecurity
> My fear here would be that you are not in control of what your
> dependencies are doing. This is
Philipp Kern writes:
> My fear here would be that you are not in control of what your
> dependencies are doing. This is especially true if you think of NIS and
> PAM, where libraries are dlopen()ed and can spawn arbitrary helper
> binaries. I remember openssh installing a syscall filter for its
On 2023-07-05 09:36, Russell Coker wrote:
On Monday, 3 July 2023 22:37:35 AEST Russell Coker wrote:
https://wiki.debian.org/ReleaseGoals/SystemdAnalyzeSecurity
People have asked how hard it is to create policy for daemons. For an
individual to create them it's a moderate amount of work, 1-2
On Monday, 3 July 2023 22:37:35 AEST Russell Coker wrote:
> https://wiki.debian.org/ReleaseGoals/SystemdAnalyzeSecurity
People have asked how hard it is to create policy for daemons. For an
individual to create them it's a moderate amount of work, 1-2 hours per daemon
which is a lot
Marco d'Itri writes:
> This is a good example of what an almost fully sandboxed service looks like:
> https://salsa.debian.org/md/rpki-client/-/blob/master/debian/rpki-client.service
My best score is a little better :-)
On Debian 11 (systemd v247):
→ Overall exposure level for
Marco d'Itri writes:
> On Jul 04, Andrey Rakhmatullin wrote:
>
>> Cool but looks like a lot of work.
[...]
>> start with applying all of them and then looking what needs to be
>> disabled?
> This is what I do.
FYI below is my basic workflow.
Once you've done 2-5 daemons, you get a "feel" for
On Jul 04, Andrey Rakhmatullin wrote:
> Cool but looks like a lot of work.
I do not think that this is really a lot of work.
> Is it possible to do this without
> applying the flags one by one and testing the result? Is it easier to
You may intimately know what the daemon needs to do and how
On Mon, Jul 03, 2023 at 11:40:18PM +0200, Marco d'Itri wrote:
> This is a good example of what an almost fully sandboxed service looks
> like:
>
> https://salsa.debian.org/md/rpki-client/-/blob/master/debian/rpki-client.service
Cool but looks like a lot of work. Is it possible to do this without
Simon McVittie wrote:
> For example, dbus-daemon can only usefully have hardening applied if it
> was built with traditional (non-systemd) service activation disabled,
> which we cannot usefully do in Debian for two reasons: because we support
> non-systemd init systems, and because we don't
Hi,
Jonathan Carter (2023-07-03):
> One shouldn't trust everything that is read on Matrix. I suggest asking
> the release team for clarification, because my last understanding is
> that release goals still exist, it's just that the release team doesn't
> want to be the entity pushing it.
FWIW,
On Jul 03, RL wrote:
> (One of the issues for services that send email is that it is very
> easy to break exim)
NoNewPrivileges breaks by design anything which depends on suid, so Exim
and (in the default configuration) Postfix.
I agree that we should do much better in terms on sandboxing,
On Mon, 03 Jul 2023 at 20:21:20 +0100, RL wrote:
> (One of the issues for services that send email is that it is very
> easy to break exim)
It's also very easy to break anything else that relies on running a
setuid/setgid/setcap executable (including many mail delivery agents,
not just Exim), as
On 2023-07-03 14:21, RL wrote:
Russell Coker writes:
https://wiki.debian.org/ReleaseGoals/SystemdAnalyzeSecurity
I think we should make it a release goal to have as many daemons as
possible running with systemd security features to aim for a low score
from "systmd- analyze security".
It
Russell Coker writes:
> https://wiki.debian.org/ReleaseGoals/SystemdAnalyzeSecurity
>
> I think we should make it a release goal to have as many daemons as
> possible running with systemd security features to aim for a low score
> from "systmd- analyze security".
This repos from Trent Buck has
Hi Russell
On 2023/07/03 14:37, Russell Coker wrote:
Someone said on Matrix that we aren't going to have official release goals in
future.
One shouldn't trust everything that is read on Matrix. I suggest asking
the release team for clarification, because my last understanding is
that
27 matches
Mail list logo
