Slackware sysvinit scripts bundled with dbus, and any
Debian derivatives that use sysvinit and have taken security updates
from at least Debian 7. Other distro-specific init system glue is up to
the relevant distro.
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
carry out a denial-of-service attack (on what? the sender? the
dbus-daemon?)
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
carry out a denial-of-service attack (on what? the sender? the
dbus-daemon?)
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
Slackware sysvinit scripts bundled with dbus, and any
Debian derivatives that use sysvinit and have taken security updates
from at least Debian 7. Other distro-specific init system glue is up to
the relevant distro.
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
implementation of eavesdropping has had side-effects in the past, which
is undesirable, and is addressed by the new monitoring interface in
version 1.9. kdbus' version of eavesdropping is quite similar to the new
monitoring interface.
--
Simon McVittie
Collabora Ltd. <http://www.collabora.
by the new monitoring interface in
version 1.9. kdbus' version of eavesdropping is quite similar to the new
monitoring interface.
--
Simon McVittie
Collabora Ltd. http://www.collabora.com/
For context, I am a D-Bus maintainer, but neither the original designer
of D-Bus nor a kdbus developer
On 17/03/15 20:42, Matthew Garrett wrote:
> On Tue, 2015-03-17 at 20:22 +0000, Simon McVittie wrote:
>> Is the intention instead that it will make privileged bits of userland
>> more careful to avoid breaking the trust chain in ways that would "fail
>> safe" by re
On 17/03/15 20:42, Matthew Garrett wrote:
On Tue, 2015-03-17 at 20:22 +, Simon McVittie wrote:
Is the intention instead that it will make privileged bits of userland
more careful to avoid breaking the trust chain in ways that would fail
safe by refusing to boot?
Not really. It's
careful to avoid breaking this trust assumption,
because the point of this patchset seems to be to make it impossible
(modulo bugs) for userland to do that.
Is the intention instead that it will make privileged bits of userland
more careful to avoid breaking the trust chain in ways that would "
of this patchset seems to be to make it impossible
(modulo bugs) for userland to do that.
Is the intention instead that it will make privileged bits of userland
more careful to avoid breaking the trust chain in ways that would fail
safe by refusing to boot?
--
Simon McVittie
Collabora Ltd. http
On 05/11/14 15:56, Andy Lutomirski wrote:
> - I tend to think that pid and tid should be separate. They're
> really their own thing, and, as noted in all the perfectly valid
> dislike directed at SO_PEERCRED, they have extremely limited value.
Traditional D-Bus has GetConnectionUnixProcessID(),
On 05/11/14 15:56, Andy Lutomirski wrote:
- I tend to think that pid and tid should be separate. They're
really their own thing, and, as noted in all the perfectly valid
dislike directed at SO_PEERCRED, they have extremely limited value.
Traditional D-Bus has GetConnectionUnixProcessID(),
On 01/11/14 16:19, Andy Lutomirski wrote:
> You can't justify logging fundamentally unverifiable things like the
> command line by saying that you want to know if someone tries to play
> (impossible-to-reliably-detect) games to obscure their command line.
I think kdbus might be mixing up two
On 01/11/14 16:19, Andy Lutomirski wrote:
You can't justify logging fundamentally unverifiable things like the
command line by saying that you want to know if someone tries to play
(impossible-to-reliably-detect) games to obscure their command line.
I think kdbus might be mixing up two
On 30/10/14 18:08, Djalal Harouni wrote:
> So, this is similar to AF_UNIX sockets. For them there's SCM_CREDENTIALS
> and SO_PEERCRED. The former uses credentials at the time of when
> messages are being sent, the latter uses the credentials at the time
> when when the connection was initially
On 30/10/14 11:52, Tom Gundersen wrote:
> For example, if you want to get the audit identity
> bits, you can now get this attached securely by the kernel, at the
> time the message is sent, rather than having to firest get the peer's
> $PID from SCM_CREDENTIALS and then read the audit identity
On 30/10/14 11:52, Tom Gundersen wrote:
For example, if you want to get the audit identity
bits, you can now get this attached securely by the kernel, at the
time the message is sent, rather than having to firest get the peer's
$PID from SCM_CREDENTIALS and then read the audit identity bits
On 30/10/14 18:08, Djalal Harouni wrote:
So, this is similar to AF_UNIX sockets. For them there's SCM_CREDENTIALS
and SO_PEERCRED. The former uses credentials at the time of when
messages are being sent, the latter uses the credentials at the time
when when the connection was initially
18 matches
Mail list logo
