thing that uses
the Red Hat or 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/>
e that recipient to
carry out a denial-of-service attack (on what? the sender? the
dbus-daemon?)
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
dbus-daemon's traditional
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
Collabo
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
of
userland be more 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 wa
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 ortho
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 esta
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
9 matches
Mail list logo
