Comment # 3 on bug 1189900 from Matthias Gerstner

I am through with the review. This D-Bus service is quite more complex than
the other. The operations it performs are okay, so it deals with state files
in /sys and reacts to udev events all related to power management, to no big
surprise.

I am seeing two problems here, however:

a) there is no authentication required to access the D-Bus interface. This
  means just any user with access to the D-Bus system bus can control power
  settings in the system. Even e.g. the 'nobody' user. This should be more
  restricted and typically the polkit authentication framework is used for
  this. Users that own a local session can then perform operations without
  special authentication and others are not allowed to do that, or need to
  enter a root password.
b) the D-Bus method net.hadess.PowerProfiles.HoldProfile allows anybody to
  register a "profile hold". This call accepts arbitrary strings that will be
  entered internally in the power-profiles-daemin into a hash map. There is no
  limit to the string lengths and no limit to the number of profile holds that
  may be active at any time. Therefore this could serve as a denial-of-service
  attack vector.

The issue in b) is demonstrated by this Python script:

```
import dbus

sbus = dbus.SystemBus()
proxy = sbus.get_object('net.hadess.PowerProfiles',
'/net/hadess/PowerProfiles')

while True:
        ret = proxy.HoldProfile("performance", "test" * 20000, "test" * 20000,
dbus_interface='net.hadess.PowerProfiles')
        if (ret % 100) == 0:
                print(ret, flush=True)
```

This will cause quickly increasing memory usage and finally an OOM.

The implementation of this D-Bus method call should probably also make sure
that the strings passed to it don't contain any malicious characters, since
the strings serve display purposes as it seems.

Are you in contact with upstream to communicate this to them or should I reach
out to them?