The IWD thread

amish · 2018-05-15 08:50:26

Majority of laptop users are also the only people having root access to that laptop. So should we allow 'sudo' to all local ttys?

One can not assume that everyone using iwd is just laptop users and only they use their laptops.

I think security should be first priority. (because someone can hijack whole network traffic)

But anyway we can close this here -- as probably right place to discuss this is upstream and not here.

Btw can anyone tell me dbus command to block iwctl to access iwd via dbus unless its root user?

Like what would be dbus address, dbus path, dbus call etc?

Pointer to any good documentation will also do. (but I do not want to learn whole dbus thing. just need basic tutorial)

Thanks in advance.

Last edited by amish (2018-05-15 12:56:32)

progandy · 2018-05-15 10:11:20

I think this will work in addition to the original iwd-dbus.conf If you only want to completely deny access without allowing access to status information, then you should be able to remove the <allow> lines.

$ cat /etc/dbus-1/system.d/iwd-strict.conf
<!-- prevent local users from changing iwd settings, 
        but allow reading status information. -->

<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>

  <policy at_console="true">
    <deny send_destination="net.connman.iwd"/>
    <allow send_destination="net.connman.iwd" send_interface="org.freedesktop.DBus.Properties" send_member="GetAll" />
    <allow send_destination="net.connman.iwd" send_interface="org.freedesktop.DBus.Properties" send_member="Get" />
    <allow send_destination="net.connman.iwd" send_interface="org.freedesktop.DBus.ObjectManager" send_member="GetManagedObjects" />
    <allow send_destination="net.connman.iwd" send_interface="net.connman.iwd.Device" send_member="RegisterSignalLevelAgent" />
    <allow send_destination="net.connman.iwd" send_interface="net.connman.iwd.Device" send_member="UnregisterSignalLevelAgent" />
  </policy>

</busconfig>

I used these documents as reference:
/usr/share/dbus-1/system.d/iwd-dbus.conf
https://dbus.freedesktop.org/doc/dbus-daemon.1.html
https://git.kernel.org/pub/scm/network/ … t/tree/doc
https://dbus.freedesktop.org/doc/dbus-s … properties

amish · 2018-05-15 13:01:24

Oh great, thanks!

That appears to be much easier than I thought!

Will try it soon.

amish · 2018-05-15 14:30:24

Added the above information / settings by progandy to iwd Wiki page.

Shibumi · 2018-05-15 16:52:22

jagan605 wrote:

amish wrote:
Yes but by default it should not allow at_console either. Because no administrator would want random user sitting on console to be able to update wifi.
For example schools, college, cyber cafe
Any random user can disconnect current wifi and make system connect to their own hotspot. And then monitor the traffic forever (till its detected)
Huge security risk.
That usecase is specific and majority of people using wifi do it in their laptops. I use wpa_supplicant in the same way so this seems logical. People with those use cases can change the dbus policy to their liking but this seems like reasonable default for the rest of us.

I agree. And I guess every administrator of a school, college or cyber cafe would prefer wired connections over wifi for fixed computers.

rsmarples · 2018-05-16 02:01:26

amish wrote:

Btw can anyone tell me dbus command to block iwctl to access iwd via dbus unless its root user?

Maybe I'm old, but the traditional way of doing this would be to set the owner:group of the local socket to root:wheel and then the file bits to allow owner:rwx, group:rwx or all:rwx.
Clear as day, not locked up in some non standard security voodoo.
If underlying security cannot be checked via `ls- l` then it's security by obscurity.

amish · 2018-05-16 03:16:07

@rsmarples
OT: I dont know how D-Bus works but I think it works with IPC which could be based on message queues and not based on sockets.

And even if there was a socket, other processes may be using same socket and hence not exclusive only to iwd / iwctl.

Trilby · 2018-05-16 11:28:22

amish wrote:

I dont know how D-Bus works but ...

That's the problem. In fact I thought that's precisely what rsmarples was highlighting:

rsmarples wrote:

... some non standard security voodoo... it's security by obscurity.

You don't know how it works, but we'll just assume it is safe? Safe from what? If you don't know how it works you can't possibly assess what it is safe from under what circumstances.

Different user accounts have worked wonderfully for decades with tools like sudo to temporarily change the effective user id as needed. This makes sense and suggests good design:

error: you cannot perform this operation unless you are root.

This does not:

Failed to restart dhcpcd@wls1.service: The name org.freedesktop.PolicyKit1 was not provided by any .service files
See system logs and 'systemctl status dhcpcd@wls1.service' for details.

But both of these are far better than this:

Which means the command that should require elevated privileges just magically worked despite not having the proper access.

amish · 2018-05-16 11:46:50

@Trilby - I do not know if you were criticizing me OR @rsmarples or none!

But I am not touching socket permissions / user OR group.

I would rather use D-Bus policy as mentioned by @progandy

Which gives this output

$ iwctl
Rejected send message, 4 matched rules; type="method_call", sender=":1.3773" (uid=1100 pid=24289 comm="iwctl ")
interface="org.freedesktop.DBus.ObjectManager" member="GetManagedObjects" error name="(unset)" requested_reply="0" destination="net.connman.iwd"
(uid=0 pid=5379 comm="/usr/lib/iwd/iwd ")
Waiting for IWD to appear...Failed to retrieve IWD dbus objects, quitting...

D-Bus disconnected, quitting...
Waiting for IWD to appear...quit

This is acceptable to me. i.e. it does not let iwctl do anything with iwd without changing permission of executable or socket.

Trilby · 2018-05-16 12:04:44

amish wrote:

@Trilby - I do not know if you were criticizing me OR @rsmarples or none!

Nope, I'm criticizing IWD.

Shibumi · 2018-05-20 18:58:51

Heyho,
I just want to mention that the iwd devs fixed some issues in the newest git version:

https://aur.archlinux.org/packages/iwd-git/

The most important ones are: Crashes with EAP-PWD and the introduction of a debug mode. (so no more log spamming)

damjan · 2018-05-20 21:51:40

Currently I use wpa_supplicant in the mode where it uses the wifi interface to associate it, but the bridge interface for the actual wpa negotiation. Something like:

 /usr/bin/wpa_supplicant -c/etc/wpa_supplicant/home.conf -bbridge0 -iwlxf8d1111881c3

This is required since my wifi interface runs in 4addr mode and is added to the bridge0 interface (together with some virtual machines).

Does IWD support this?

Shibumi · 2018-05-21 20:26:19

@damjan
I don't think so. Sorry

@All

I have pushed a new version to community 0.2-2. This should come with a working service file now. Furthermore you can specify your interface now with the service. So you can do something like: systemctl enable iwd@wlp3s0.service --now

amish · 2018-05-22 01:11:38

Please keep upstream iwd.service as well. Why delete it?! (Or fixed version as below)

This way those who want iwd to pick interface automatically will also work.

Otherwise this will require everyone to REDO all things (delete old service - find interface - add new service with interface) and also change Wiki pages.

I would also like to suggest following changes to iwd.service file

[Unit]
Before=network.target
Wants=network.target

[Install]
WantedBy=multi-user.target

Last edited by amish (2018-05-22 02:05:13)

amish · 2018-05-22 02:14:58

Suggestions for PKGBUILD:

1) iwd@.service has no sha512sum (its mentioned as SKIP). Please add it.
2) Please do not delete upstream iwd.service file because its buggy but instead replace it with FIXED version (just 3 line change is required)

source=(... iwd.service ...)
package(){
...
    # include both iwd.service and iwd@.service
    install -Dm644 -t "${pkgdir}/usr/lib/systemd/system" "${srcdir}"/iwd{,@}.service
...
}

3) Cosmetic changes - indentation is bad and random

Last edited by amish (2018-05-22 02:18:27)

RonObvious · 2018-05-28 17:43:35

I have a suggestion, or a request, if you will, for the Wiki page: More information about the NetworkManager integration, please.

I currently use NetworkManager and am reasonably happy with it (on my Notebook). It's not perfect, but I wouldn't have really given the IWD announcement much thought if I hadn't seen that there is NetworkManager integration. However, the wikipedia just says that there is an integration, and then drops the subject and moves on to what appears to be instructions for a pure IWD network configuration (without NM et. al.).

Which made me suspect I was over-thinking it. Perhaps I didn't need to read much more than that, perhaps it's easy (I thought) -- which would explain why it's not described in the Wikipedia! Right?

But that didn't work out. I installed IWD, enabled and started the service. Later, I saw here in this thread that I should have stopped and disabled wpa_supplicant first -- OK, makes sense -- but it would have been helpful to have that in the Wikipedia page (assuming it's correct?). So anyway, I got that far. Then I tried connecting, using NM, just to see if NM could automate everything, and lo and behold -- it worked! Or rather, it seemed to work; but then I figured out that NM had invoked wpa_supplicant, and that it had worked. IWD was running, co-existing with wpa-supplicant, but not doing anything (apparently).

A quick internet search showed me a man page for NetworkManager.conf, which mentions IWD, and has a little information about configuring NM to use IWD instead of wpa_supplicant -- but then I noticed that this was not the same as my local copy of that man page (Version 1.11 instead of 1.10) and I got scared off the whole undertaking. Perhaps I need to wait for the next version of NM?

Bottom Line: If the NM integration is not yet usable (at least with the version of NM from the extra repository (1.10.8)), it would be good to be warned away from it (for the time being). On the other hand, if the NM integration is usable, and I was just doing it wrong, it would be helpful to be told a bit more about how to make it work.

Thanks in advance!

Last edited by RonObvious (2018-05-28 17:46:10)

Slithery · 2018-05-28 17:49:54

RonObvious wrote:

I have a suggestion, or a request, if you will, for the Wiki page

It's a wiki, why don't you do it?

RonObvious · 2018-05-28 18:20:59

Slithery wrote:

It's a wiki, why don't you do it?

Two reasons:

Because this thread started out with a "call for feedback" ("I thought it would be a good idea to collect early impressions and experiences here. Relevant information can then be added to the wiki as necessary.").
More to the point, as I hoped my comment would make clear, I'm anything but confident about this. I half expect someone here to point out something that -- perhaps not only in retrospect -- will be blindingly obvious. In which case I will gladly retract my suggestion.

Of course, I could have taken this to the "Discussion" page in the wiki, but this thread is active (rather!), and the discussion page is blank, so this seems like the place to go.

Put another way -- before I write something in the wiki like "NM users should stay away from IWD for the time being" (I wouldn't phrase it quite like that, but it would boil down to as much), I would like some confirmation that this is correct and not over-reacting or otherwise based on ignorance and impatience on my part.

jasonwryan · 2018-05-29 07:56:38

Shibumi, the connman page has been updated with a section on replacing wpa_supplicant with iwd https://wiki.archlinux.org/index.php/Co … supplicant

Can you confirm this approach? I have tried it and keep running into the "/net/connman/technology/wifi: Not supported" error and I am unclear about the benefit, or necessity, of those service files.

amish · 2018-06-16 01:33:48

@Shibhumi - please do not randomly add and remove .service file.

in version 0.2-2 you removed iwd.service breaking my internet and introduced iwd@.service file.

in version 0.3-1 you removed iwd@.service file and re-introduced iwd.service file which again broke my internet. (because I had started using iwd@.service file)

I can understand that iwd is something new but that does not mean that you knowingly make people do research on what was changed and what broke their things.

And even if you still want to do that then please "echo" the same in .install file. So that users of iwd know that they need to change settings.

Also I do not think iwd.service is still fixed properly.

It just says "WantedBy=multi-user.target".

It does not say "Before" what - which means that it may start after all the services which need internet and which can cause issues. (like system time out of sync)

There must be line similar to what is in wpa-supplicant.service

[Unit]
...
Before=network.target
Wants=network.target

Please fix it even if upstream does not.

Thank you

Last edited by amish (2018-06-16 01:34:39)

seagull · 2018-06-16 08:14:50

Please make no such ad hoc changes to such a vital package! This deserves mentioning/announcing on the archlinux front page. Thanks

jasonwryan · 2018-06-16 08:20:21

seagull wrote:

Please make no such ad hoc changes to such a vital package! This deserves mentioning/announcing on the archlinux front page. Thanks

JFC: if this was worthy of the front page, we'd need a ticker with all the announcements. Arch is a rolling release; things will change. If you can't, or won't deal with that, find something else. But please stop calling for every. little. change. to be announced.

amish · 2018-06-16 08:37:17

Yes this does not require front page announcement.

But maintainer should take care not to break functioning internet. (happened twice in as many releases).

Arch is rolling release so upstream changes can break things - completely agree.

But breaking things at discretion is not correct in my opinion.

Last edited by amish (2018-06-16 08:37:42)

jasonwryan · 2018-06-16 08:40:35

The changes to the service file come from upstream: it is not the packagers fault.

amish · 2018-06-16 09:00:03

Nope - it seems that you are probably not using iwd. Hence do not know what has happened.

https://git.archlinux.org/svntogit/comm … ckages/iwd

But anyway ... lets move on.

Last edited by amish (2018-06-16 09:02:07)

Arch Linux

#26 2018-05-15 08:50:26

Re: The IWD thread

#27 2018-05-15 10:11:20

Re: The IWD thread

#28 2018-05-15 13:01:24

Re: The IWD thread

#29 2018-05-15 14:30:24

Re: The IWD thread

#30 2018-05-15 16:52:22

Re: The IWD thread

#31 2018-05-16 02:01:26

Re: The IWD thread

#32 2018-05-16 03:16:07

Re: The IWD thread

#33 2018-05-16 11:28:22

Re: The IWD thread

#34 2018-05-16 11:46:50

Re: The IWD thread

#35 2018-05-16 12:04:44

Re: The IWD thread

#36 2018-05-20 18:58:51

Re: The IWD thread

#37 2018-05-20 21:51:40

Re: The IWD thread

#38 2018-05-21 20:26:19

Re: The IWD thread

#39 2018-05-22 01:11:38

Re: The IWD thread

#40 2018-05-22 02:14:58

Re: The IWD thread

#41 2018-05-28 17:43:35

Re: The IWD thread

#42 2018-05-28 17:49:54

Re: The IWD thread

#43 2018-05-28 18:20:59

Re: The IWD thread

#44 2018-05-29 07:56:38

Re: The IWD thread

#45 2018-06-16 01:33:48

Re: The IWD thread

#46 2018-06-16 08:14:50

Re: The IWD thread

#47 2018-06-16 08:20:21

Re: The IWD thread

#48 2018-06-16 08:37:17

Re: The IWD thread

#49 2018-06-16 08:40:35

Re: The IWD thread

#50 2018-06-16 09:00:03

Re: The IWD thread

Board footer