"dbus-monitor --system" stopped monitoring method calls remotely

[L A Walsh]

Simon McVittie wrote:
> On Thu, 12 Jul 2018 at 19:37:47 -0700, L A Walsh wrote:
>   
>> Simon McVittie wrote:
>>     
>>> * on a totally trusted LAN in conjunction with NFS-shared home
>>>   directories on Unix (but in 2018 I don't think this is really valid
>>>   any more, because LANs that you can totally trust are increasingly rare)
>>>       
>> ----     Lans that only only have secure connections to them, such as ssh
>> or vpns, are rare?
>>     
>
> Unfortunately yes. As soon as an untrusted (either malicious or
> easily-hacked) mobile phone, printer, TV, smart lightbulb, etc. gets
> access to the LAN, that device can eavesdrop on all unencrypted
> communications on that LAN and can impersonate other devices on that
> LAN. D-Bus is not suitable for such environments.
>   
---
    Ok, none of those are on my closed network, and of the few
that are on the semi-closed network, they still have no direct
access to/from the internet.  Indirectly, they can initiate outgoing
connections, but incoming connection would be more difficult.

    But most companies with a desire to protect their network
wouldn't allow uncontrolled devices to access their network, or use
a vpn layer for secure communications that would prevent random
devices from reading or connecting with anything.

    Perhaps among the general public such networks are rare, but
among companies that care about such things, I see them being the rule
rather than the exception.

    Even as far back as the mid-late 90's (~20 years ago) polices
for home users connecting to the network were to use black-box
firewalls that sat on your incoming home cable connection. 
They allowed non-company connected devices full access to the
outside world and zero access to the company net.  Vice-versa
was also true...connected to internal net meant no access to external
nets.  Software running on the computer verified no other network
connections  while connected to company net. 

    Of course these setups weren't designed to be impervious to
a determined hacker, but this was over 20 years ago and employees
were generally thought to not be malicious.  Further evolving
devices can use things like 'trusted execution' to ensure a
trusted-based of software is used -- even going so far as
to use the TPM for a trusted boot with measured integrity, but
I've never worked such devices. 

In your estimates of how prevalent such networks are, you might want
to consider that those who run such networks don't usually advertise
them, nor advertise what methods they use to secure them.  They
don't want to advertise "challenge" machines, since by the very
fact of claiming a secure network, they invite hack attempts --
and nothing is 100% safe if hackers are motivated enough.

>   
>>> If you are using the ANONYMOUS authentication mechanism, that is doubly
>>> insecure. I am seriously considering removing <allow_anonymous/> from
>>> the dbus-daemon: it might occasionally be valid for "peer to peer" D-Bus, but it is not a reasonable thing to do for a dbus-daemon.
>>>       
I can't really say how useful an ANONYMOUS authentication mechanism is
or not.  But I know how to rebuild most packages.  Can't speak for others,
but if I have to put in too many customizations, it makes me less likely
to want updates. 

    Can't imagine many customers aren't thinking along similar lines
with so many devs releasing beta (if not alpha) quality updates these days.

> The standard system bus is designed to connect mutually distrusting
> processes ...
> Conversely, the standard session bus is designed to connect mutually
> trusting processes ...
----
    All I know is the more things that get connected to dbus, the
more my system loses features.  Most utilites no longer save their
state because dbus isn't running or isn't configured correctly.

    Any attempts I've made to get it working have been met with 'not
supported', or 'not designed for that'.  Lovely -- adding a bus that
isn't designed to work with the console on a separate system from
the OS.  I can run a separate instance of either bus on my console-system,
but no way to connect it to the main system -- with current and future
plans looking like the intention is to make remote-access harder
rather than fixing the problems. 

    You want to make a guess at how many software engineers have
android or linux-compat systems with a secure connection to their
home systems that won't be able to effectively join them to get a
usable and useful session out of their potentially secure link
with their home system? 

    _Most_ of the people who have uncontrolled access for their
Internet-of-things on their home network are probably NOT using
linux at home and connecting with a secure connection from another
linux type box.  Yet for the minority that might you want to further
limit the capabilities?  More and more, people are connecting to
remote machines in the 'cloud' with portables.  That's going to be
the dominant paradigm in the coming compute-age. How is Dbus going
to survive past the local LAN becoming a rarity?
>
>   
>>> Exposing D-Bus over TCP and enabling ANONYMOUS authentication were
>>> among the factors that led to a recall of 1.4 million unsafe vehicles:
>>> <http://www.bbc.co.uk/news/technology-33650491>.
>>>       
>> ----
>>    Vehicles are a poor comparison to a stationary, closed environment.
>>    Especially, since vehicles almost never (maybe never?) use a wired
>> connection on a closed network.  
>>     
>
> In-vehicle network developers assumed that their environment was closed
>   
In-vehicle network that is known to have wireless connections?  Seriously?
You wanna compare that to a direct-connect hardwired cable that can't
leave the premises and has no wireless on the premises other than
a portable handset for a landline phone?


>>> To monitor the system bus, you will need to be either root (uid 0) or
>>> the uid that is running the system bus (usually named messagebus or
>>> dbus, but it depends on your OS distribution). To monitor a session
>>> bus, you need to be the same uid that is running the session bus.
>>>       
>> ---
>>    You don't use access lists or standard unix/linux access mechanisms?
>>     
>
> Kernel-level access control determines who can connect to the bus; in
> the case of the system bus that's "everyone", and in the case of the
> session bus that's just your own uid. For the system bus, dbus-daemon
> needs to do its own access control within that, to determine who can
> and can't do particular privileged operations.
>
> Older versions of dbus-daemon had general-purpose access control lists
> to control everything (including privileged operations), but it came to
> our attention that several system services misconfigured those ACLs to be
> very insecure (CVE-2014-8148 is a particularly bad example). As a result,
> to mitigate misconfigurations like that one, we've moved towards a model
> where the most sensitive operations (like monitoring) are hard-coded..
>   
So rather than distributing secure defaults with multi-level resets,
and fixing the problem, or creating any sort of monitoring or warning
ability to check for misconfigurations, or an easier configuration
system that my mom could use, you hard code out alternatives. 

Whatever happened to "user friendly design"?  What about making
the configuration system (or a subset) *easy* to use via a GUI? 

The dbus configuration language & config system is FAR from easy
for a lay-person to use.  Why not fix that rather than taking a blame-
the user and lock-it-up approach?  Way too many pieces of software have
gone the extreme opposite of user friendly -- I'm sure you are
familiar with more than one computer language whose developers consider
their incomprehensibility to be a feature! 

Some software designers make configuration difficult, thinking it will
keep people from trying to configure it.

Admittedly I'm familiar with it over the years, but I find the linux
kernel easier to configure than DBUS.  Would you disagree?


> Not all OS kernels apply filesystem-level permissions to path-based
> AF_UNIX sockets, Linux does not apply filesystem-level permissions to
> abstract AF_UNIX sockets (which don't exist in the filesystem at all),
>   
Right...and that's why.  If the object doesn't exist in the kernel, how
can it lock it down?

> and as far as I'm aware no kernel applies filesystem-level permissions to
> TCP sockets, so we cannot rely on standard filesystem-level permissions
> here - if we did, the resulting system would be insecure.
>   
Probably because no one has done work no TCP sockets in 'forever'.
But the sockets themselves are inodes in a file system, that means
some basic access control should be applicable from the file system.

How many OS's other than linux are currently supported?  How many of those
don't have some form of access list?  I see DBUS and the freedesktop
having linux as about 90% (maybe more) of its customer-base.  Maybe BSD
as a second...I don't know.  At worse, you can go to a meta-info
DB owned by root and accessible via daemon sitting someone on the file
system (presuming the OS has some idea of a protected file).

>
> A fully configurable ACL would be more flexible, yes, but it's one more
> thing that can go horribly wrong, and we should always err on the side of
> safety at security boundaries.  
>   
Anything and everything can go wrong. Too many SW projects seem to
just be willing to throw out the baby with the bathwater, so to speak.

>   
>>> On dbus 1.10+
>>> (Ubuntu 16.04/xenial or later) the instructions for the system bus can
>>> be simplified to: "Run sudo dbus-monitor --system".
>>>       
>> ---
>>    Might as well suggest:
>>
>>    # chmod u+s dbus-monitor
>>     
>
> No, never do this.  
The simplification above, of putting sudo in front of it can be
equivalent. 
> dbus-monitor is not designed to be a security boundary.
>   
But it could be executable only by people in a specific group
or on an access list.  That it would be setuid root would be
what the ACL would basically be controlling access to.  Sudo can
provide the same, worse or better security.  Making dbus-monitor setuid
root could be a good thing if dbus were aware of system capabilities
as well.  It could just drop capabilities it didn't need, as well,
though I am guessing it really doesn't need much in the way of
system capabilities - just network (including local sockets in that
category) capability.

> Only programs that are designed to act as a security boundary (such as
> sudo, su and dbus-daemon-launch-helper) can safely be setuid.
>
> If you don't like setuid (and you're right to dislike it, but it's one
> of the tools in the Unix toolbox), users with suitable credentials can
> also arrange for code to be run as root via inter-process communication,
> for instance by sending D-Bus messages to systemd (for which authorization
> will be confirmed via polkit) or by opening a loopback ssh connection.
>   
---
    I like set-capability programs better, but setuid is often the
only thing a program that only understands UID==0 will work with (*hint*).

    Why 'root', why not a special UID?  Does it need root?  or could
it do with specific capabilities?  Pah... I need to connect separate
system buses together so they can act as 1 system (that's how the
system was setup and that's how the security model is setup).  May
not be true for everyone, but I bet there are many similar use cases.

    And I FWIW, I generally optimize for speed/low delay with I can.
I do with with CIFS for my connections -- not NFS.

Cheers, forgive my the cynicism in my tone at places...it's not
you or your specific project...its just having been around computers
and software for a long while and seen their promise and seeing
their decline over the past couple of decades 0-- ick.

Linda Walsh