allow non-root users to use ddccontrol #5
Comments
|
This is:
|
Hm, that's true. So it should probably use PolicyKit instead. That would require major changes though. |
|
I'm not sure that this is security hole, because |
|
The security hole lies at complete access to all i2c devices. Not at becoming i2c group member. And, this could have following consequences:
|
|
This could easily turn into a huge security risk, especially given that you have parsing in the same code base. Do not do this unless you have had the code audited by external parties, professionally. Strongly suggest using something like Rust for any code doing this, rather than C. Yes, this would be a major undertaking. |
|
In fact, you could easily imagine someone with non-root physical access attaching a malicious hdmi device (a tiny dongle with a hdmi plug on it) that performs an overflow on your parser, and allows non-root calls to ddccontrol to provide a root shell. Building something like this is less involved than one might think. |
|
@cheater well you've commented after #34 was merged. But, it's a valid point. I also test daemon with However, daemon can run under a different user, which will be given privileges to access i2c devices. From security point of view, daemon launched as a different user might be the most safe way of execution:
|
|
this will not be done by package maintainers.
…On Mon, 18 Jun 2018, 20:27 Miroslav Kravec, ***@***.***> wrote:
@cheater <https://github.com/cheater> well you've commented after #34
<#34> was merged. But, it's
a valid point. I also test daemon with valgrind. But, there might still
be some vulnerabilities.
However, daemon can run under a different user, which will be given
privileges to access i2c devices.
From security point of view, daemon launched as a different user might be
the most safe way of execution:
- no root access,
- no access to data of current user (assuming user has set correct
permissions on his filesystem,...).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#5 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAL7PqhuoqpXYy_s40mvCnNe7qY1h9Vxks5t9_EGgaJpZM4EJGTp>
.
|
In order to perform attack:
I cannot imagine people investing their time to perform real attack. I can imagine someone doing that to prove that it's possible, or to have fun,... But, not in real world.... It's not something, which would be running on servers, and computers of common users are not that much of target... And, if they are a target, it's easier to steal whole computer, and access non-encrypted HDD. |
@cheater I thought of two options:
|
|
Of course package maintainers are capable of creating packages which run system services as unprivileged system users. Have a look at cups (runs as lp), avahi, ... |
|
i disagree with your security analysis - it is not backed up by any sort of
formal infosec research. i don't think you have considered all the possible
attack vectors. i think you just imagined some situations that you could
come up with on the spot, and because you couldn't immediately imagine a
way to exploit them, you concluded no exploit was possible. That's a common
pitfall in infosec. it's also why not having capabilities in the
firstvplace is a much better idea than trying to secure their use.
…On Mon, 18 Jun 2018, 20:34 Miroslav Kravec, ***@***.***> wrote:
Do not do this unless you have had the code audited by external parties,
professionally.
ddccontrol is not very used software, though,.. Mostly by individuals,
who use it at their home PC, with poor lighting conditions, to adjust
brightness, or to play with their monitor's settings. So, there's no huge
risk of damage caused by exploiting ddccontrol,...
In order to perform attack:
- attacker, or companion, must be in physical presence of target
computer,
- must know and be sure, that target computer uses Linux and has
running ddccontrol daemon,
- must be capable to create HDMI dongle, which can exploit ddccontrol,
- must it be worth it,...
I cannot imagine people investing their time to perform real attack. I can
imagine someone doing that to prove that it's possible, or to have fun,...
But, not in real world.... It's not something, which would be running on
servers, and computers of common users are that target. And, if they are
target, it's easier to steal whole computer, and access non-encrypted HDD.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#5 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAL7PjgT8YSRXg74tUMHP2DyEH9S18JUks5t9_KbgaJpZM4EJGTp>
.
|
|
Stefan, capable and willing are two different things ...
…On Mon, 18 Jun 2018, 20:42 cheater00 cheater00, ***@***.***> wrote:
i disagree with your security analysis - it is not backed up by any sort
of formal infosec research. i don't think you have considered all the
possible attack vectors. i think you just imagined some situations that you
could come up with on the spot, and because you couldn't immediately
imagine a way to exploit them, you concluded no exploit was possible.
That's a common pitfall in infosec. it's also why not having capabilities
in the firstvplace is a much better idea than trying to secure their use.
On Mon, 18 Jun 2018, 20:34 Miroslav Kravec, ***@***.***>
wrote:
> Do not do this unless you have had the code audited by external parties,
> professionally.
>
> ddccontrol is not very used software, though,.. Mostly by individuals,
> who use it at their home PC, with poor lighting conditions, to adjust
> brightness, or to play with their monitor's settings. So, there's no huge
> risk of damage caused by exploiting ddccontrol,...
>
> In order to perform attack:
>
> - attacker, or companion, must be in physical presence of target
> computer,
> - must know and be sure, that target computer uses Linux and has
> running ddccontrol daemon,
> - must be capable to create HDMI dongle, which can exploit ddccontrol,
> - must it be worth it,...
>
> I cannot imagine people investing their time to perform real attack. I
> can imagine someone doing that to prove that it's possible, or to have
> fun,... But, not in real world.... It's not something, which would be
> running on servers, and computers of common users are that target. And, if
> they are target, it's easier to steal whole computer, and access
> non-encrypted HDD.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#5 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAL7PjgT8YSRXg74tUMHP2DyEH9S18JUks5t9_KbgaJpZM4EJGTp>
> .
>
|
|
as Miroslav said, this is a piece of software not used by many. it will not
get the same attention avahi etc would get. yet it will still be in a
verifiably genuine package that a user could end up with on their system,
knowingly or not. this opens a lot of doors for exploitation.
…On Mon, 18 Jun 2018, 20:43 cheater00 cheater00, ***@***.***> wrote:
Stefan, capable and willing are two different things ...
On Mon, 18 Jun 2018, 20:42 cheater00 cheater00, ***@***.***>
wrote:
> i disagree with your security analysis - it is not backed up by any sort
> of formal infosec research. i don't think you have considered all the
> possible attack vectors. i think you just imagined some situations that you
> could come up with on the spot, and because you couldn't immediately
> imagine a way to exploit them, you concluded no exploit was possible.
> That's a common pitfall in infosec. it's also why not having capabilities
> in the firstvplace is a much better idea than trying to secure their use.
>
> On Mon, 18 Jun 2018, 20:34 Miroslav Kravec, ***@***.***>
> wrote:
>
>> Do not do this unless you have had the code audited by external parties,
>> professionally.
>>
>> ddccontrol is not very used software, though,.. Mostly by individuals,
>> who use it at their home PC, with poor lighting conditions, to adjust
>> brightness, or to play with their monitor's settings. So, there's no huge
>> risk of damage caused by exploiting ddccontrol,...
>>
>> In order to perform attack:
>>
>> - attacker, or companion, must be in physical presence of target
>> computer,
>> - must know and be sure, that target computer uses Linux and has
>> running ddccontrol daemon,
>> - must be capable to create HDMI dongle, which can exploit
>> ddccontrol,
>> - must it be worth it,...
>>
>> I cannot imagine people investing their time to perform real attack. I
>> can imagine someone doing that to prove that it's possible, or to have
>> fun,... But, not in real world.... It's not something, which would be
>> running on servers, and computers of common users are that target. And, if
>> they are target, it's easier to steal whole computer, and access
>> non-encrypted HDD.
>>
>> —
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub
>> <#5 (comment)>,
>> or mute the thread
>> <https://github.com/notifications/unsubscribe-auth/AAL7PjgT8YSRXg74tUMHP2DyEH9S18JUks5t9_KbgaJpZM4EJGTp>
>> .
>>
>
|
Well, neither is your's disagreement... But, as you stated:
And, with this attitude:
I shouldn't run any system daemon, because it can be target of an exploit,.. Especially, daemon listening to network (agree on that), but also other daemons,... Mainly, I'd rather run no kernel, because drivers have got lot's of capabilities, too. (sorry for irony,... but,...) I agree, that it's important to think about security. But, this level could be called paranoia. |
Good point. However, I'm pessimistic about this, too. I doubt, that package maintainers will be willing to do that. I assume, that they've got different priorities, than securing So, I thought to prepare upstream sources for everything. And, package would just need to create an user for daemon execution... Or, find some other way to setup secure privileged access to i2c devices for daemon,... EDIT: but I also doubt, that ddccontrol will be exploit target, at least not so soon,... |
|
i think you are escaping to hyperbole. the example with malicious hdmi was
just to make a point. software has as you know more complex and subtle bugs
but they are useless for illustrating issues in a conversation. the gist of
the issue is you are running a parser and other complex libraries in an
always-available process that has root access, for no reason other than
because you want (non-existent, hypothetical) applets to update a bit more
easily. i think there was some other point that escapes me now but which
did not make a daemon /necessary/. that's a lot of security risk and a
large exploitable area being added for little return - and that's why i
think it's not a good trade. you are one developer, who is for now
interested in this project. but who is going to maintain the huge
exploitable area you add? are you even aware what's in store? i just think
you are making this jump too lightly, and i think this could make the
project considerably less healthy than it is now in its simple form.
…On Mon, 18 Jun 2018, 20:51 Miroslav Kravec, ***@***.***> wrote:
@cheater <https://github.com/cheater>
i disagree with your security analysis - it is not backed up by any sort of
formal infosec research
Well, neither is your's disagreement... But, as you stated:
... you could easily imagine someone with non-root physical access
attaching a malicious hdmi device (a tiny dongle with a hdmi plug on it)
that performs an overflow on your parser ...
And, with this attitude:
it's also why not having capabilities in the firstvplace is a much better
idea than trying to secure their use.
I shouldn't run any system daemon, because it can be target of an
exploit,.. Especially, daemon listening to network (agree on that), but
also other daemons,... Mainly, I'd rather run no kernel, because drivers
have got lot's of capabilities, too. (sorry for irony,... but,...)
I agree, that it's important to think about security. But, this level
could be called paranoia.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#5 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAL7Pmargz9BtYyLoMhAn8hU1OB2Zcf6ks5t9_aigaJpZM4EJGTp>
.
|
|
Separating the agent from the GUI is a definitive security win. Being able to cache e.g. EDID data is just a nice side effect. |
|
I don't know how other distributions work, but on openSUSE every new package with elevated privileges is security audited. And doing proper packaging is the first reason for distributions to exist. |
|
that's the practice, in theory.
…On Mon, 18 Jun 2018, 21:10 StefanBruens, ***@***.***> wrote:
I don't know how other distributions work, but on openSUSE every new
package with elevated privileges is security audited. And doing proper
packaging is the first reason for distributions to exist.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#5 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAL7PlrOlpStO6-WjyWkDZmRieOou0fvks5t9_srgaJpZM4EJGTp>
.
|
|
@cheater ok, then from security perspective, daemon running under different user is gain,... It's better, than running daemon under root, or running previous implementation with And, I'm not taking this lightly,... As for now, you've done more than enough criticism. Though, I appreciate your effort, this conversation leads nowhere good anymore. Rather than continuing conversation as argumentation against/for d-bus daemon, we could work on solution,.. D-Bus daemon is gain, security is important,... let's just work on that, and make everybody happy. |
|
@cheater if you have some solution design in mind, you're free to propose it. I'm willing to put my effort to implement it. |
|
i would consider building this part in rust, as it has secure parsers and a
markedly lower prevalence of exploits than other languages suited for low
level tasks like this (python, C). note: i am not a rust programmer, so i'm
not trying to push a favorite tool - i just think it would be very well
suited here. if you can't use rust, use ATS, which has similar goals and
power to rust and compiles down to C.
as for the daemon and the command line tool, i would much rather have the
daemon just cache data and coordinate UI controls (MVC or whatever we want
to use), meanwhile any requests are made via a non-resident subprocess that
can ask for root privileges via eg gksudo. access without sudo can
optionally be given via a special user like described above. the worker
should have a separate code base and repo to prevent sharing of code
between it and the daemon. the worker should not trust any data provided by
the daemon and should always validate it and know if the data is
instructing it to do something potentially dangerous.
…On Mon, 18 Jun 2018, 21:22 Miroslav Kravec, ***@***.***> wrote:
@cheater <https://github.com/cheater> if you have some solution design in
mind, you're free to propose it. I'm willing to put my effort to implement
it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#5 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAL7PqmVL5P4zWND3hx-RPQM-97hQgCLks5t9_3jgaJpZM4EJGTp>
.
|
I have opened #57 for rewrite discussion.
It would introduce too much spaghetti to communication. I'd rather have layered approach:
|
|
why would there be "spaghetti"?
…On Tue, 19 Jun 2018, 19:00 Miroslav Kravec, ***@***.***> wrote:
i would consider building this part in rust, as it has secure parsers and a
markedly lower prevalence of exploits than other languages suited for low
level tasks like this (python, C).
I have opened #57 <#57>
for rewrite discussion.
as for the daemon and the command line tool, i would much rather have the
daemon just cache data
It would introduce too much spaghetti to communication. I'd rather have
layered approach:
- daemon performing HW access with security in mind,
- GUI/CLI clients exposing DDC/CI control to user.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#5 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAL7Pmr8YldHJSb53R6hiNos0CWuterDks5t-S4egaJpZM4EJGTp>
.
|
|
|
|
For future readers, follow this tutorial https://frdmtoplay.com/using-ddccontrol-as-a-non-root-user/. Just note that there's a typo. In the udev rule in |
To allow non-root users to run ddccontrol we need to do these steps:
groupadd --system i2cdev30-i2c-tools.rules) containing this line:KERNEL=="i2c-[0-9]*", GROUP="i2c", MODE="0660"(5. add user to group i2c – this step has to be done by the user/admin. Suggest that to the user in case ddccontrol can't find a monitor to connect to. Command:
usermod -G i2cdev username)With these steps (g)ddccontrol can be run as ordinary user.
(source/idea: http://www.techytalk.info/debian-ubuntu-gddccontrol-non-root/ and debian package, https://packages.debian.org/stable/i2c-tools )
The text was updated successfully, but these errors were encountered: