On Sun, 01.02.15 09:28, Topi Miettinen (toiwo...@gmail.com) wrote:
On 01/27/15 22:19, Lennart Poettering wrote:
On Tue, 27.01.15 21:58, Topi Miettinen (toiwo...@gmail.com) wrote:
Well, the way I read the paragraph above if we set PR_SET_NO_NEW_PRIVS
after forking, but before execing
On Sun, 01.02.15 11:21, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:
El 27/01/15 a las 21:18, Lennart Poettering escribió:
On Tue, 27.01.15 15:12, Cameron Norman (camerontnor...@gmail.com) wrote:
Lennart: if you really want to test the profile, you just need to spin
up an OpenSuSE,
On 01/27/15 22:19, Lennart Poettering wrote:
On Tue, 27.01.15 21:58, Topi Miettinen (toiwo...@gmail.com) wrote:
Well, the way I read the paragraph above if we set PR_SET_NO_NEW_PRIVS
after forking, but before execing systemd-timesyncd, and that binary
has an selinux label on it, that the
El 27/01/15 a las 21:18, Lennart Poettering escribió:
On Tue, 27.01.15 15:12, Cameron Norman (camerontnor...@gmail.com) wrote:
Lennart: if you really want to test the profile, you just need to spin
up an OpenSuSE, Ubuntu, or Debian VM (on debian you need to install
and enable apparmor, which
On 01/27/15 01:54, Lennart Poettering wrote:
On Sun, 25.01.15 12:23, Topi Miettinen (toiwo...@gmail.com) wrote:
There's no need for CAP_CHOWN, CAP_DAC_OVERRIDE or CAP_FOWNER.
Hmm, that's not true, is it? load_clock_timestamp() is invoked before
we drop privs in the daemon. And it certainly
On Tue, 27.01.15 19:47, Topi Miettinen (toiwo...@gmail.com) wrote:
On 01/27/15 01:54, Lennart Poettering wrote:
On Sun, 25.01.15 12:23, Topi Miettinen (toiwo...@gmail.com) wrote:
There's no need for CAP_CHOWN, CAP_DAC_OVERRIDE or CAP_FOWNER.
Hmm, that's not true, is it?
On 01/27/15 21:16, Lennart Poettering wrote:
On Tue, 27.01.15 19:47, Topi Miettinen (toiwo...@gmail.com) wrote:
On 01/27/15 01:54, Lennart Poettering wrote:
On Sun, 25.01.15 12:23, Topi Miettinen (toiwo...@gmail.com) wrote:
There's no need for CAP_CHOWN, CAP_DAC_OVERRIDE or CAP_FOWNER.
On Tue, Jan 27, 2015 at 1:16 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Tue, 27.01.15 19:47, Topi Miettinen (toiwo...@gmail.com) wrote:
I'm not sure. Shouldn't we then ship a SELinux policy file then? Would
you be interested in AppArmor profile for timesyncd, I have one? Also,
if
On Tue, 27.01.15 21:58, Topi Miettinen (toiwo...@gmail.com) wrote:
Well, to enable stateless systems I think it is a good idea to write
services in a way that they can rebuild what they need in /var on
their own, should it be missing, so that /var can be flushed out and
things will just
On Tue, 27.01.15 15:12, Cameron Norman (camerontnor...@gmail.com) wrote:
Lennart: if you really want to test the profile, you just need to spin
up an OpenSuSE, Ubuntu, or Debian VM (on debian you need to install
and enable apparmor, which takes a short while).
Well, I have no personal
On Tue, Jan 27, 2015 at 1:58 PM, Topi Miettinen toiwo...@gmail.com wrote:
Well, I'm no expert on AppArmor policies. This is what I have:
#include tunables/global
/lib/systemd/systemd-timesyncd {
I am not sure how that would be done, but this needs to handle
timesyncd being in
On Tue, 27.01.15 14:58, Cameron Norman (camerontnor...@gmail.com) wrote:
On Tue, Jan 27, 2015 at 1:16 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Tue, 27.01.15 19:47, Topi Miettinen (toiwo...@gmail.com) wrote:
I'm not sure. Shouldn't we then ship a SELinux policy file then?
On Sun, 25.01.15 12:23, Topi Miettinen (toiwo...@gmail.com) wrote:
There's no need for CAP_CHOWN, CAP_DAC_OVERRIDE or CAP_FOWNER.
Hmm, that's not true, is it? load_clock_timestamp() is invoked before
we drop privs in the daemon. And it certainly calls fchmod() and
fchown(), so that it can later
There's no need for CAP_CHOWN, CAP_DAC_OVERRIDE or CAP_FOWNER.
No new privileges are needed, especially no setuid fixups are expected.
Device policy can be closed, timesyncd does not access any devices.
Timesyncd only needs write access to /var/lib/systemd/clock. There's no
need to access /boot
14 matches
Mail list logo
