Another option would be “manual uninstallation”. I.e. undoing the effects (deleting files, changing config back) of any file shipped by package kicksecure-network-conf.
nm-tray and network-manager-gnome work after a reboot. We should only use one however. The gnome front-end is more aesthetic and easier to interact with.
Can no longer reproduce this and networking seems to work without the package installed.
If you are going with Network manager, these are usually the relevant networking files for config and such: the /etc/NetworkManager directory which has /NetworkManager.conf. To make NM be the default networking, simply add [ifupdown] and under it put managed=false (in the Networkmanager.conf). in the “system-connections” folder under the same directory is where you define your default interface connection, applicable wifi, dns servers, ipv4/ipv6 etc. usually the file name is your access point/router name or whatever.
There is a built in conf.d folder for customizations and things.
If using dhcp, there is usually a dhclient script in /bin or /sbin. You can confine this with apparmor easily. There is a isc-dhcp package for obtaining addresses automatically.
Also, don’t forget nm comes with a useful tui interface. get to it by going to cli and type: nmtui . You can add connections, edit them, etc.
Edit: oh yeah, I forgot about dns.
You can use systemd-resolved and mask the systemd-networkd service. Or, nm can handle dns totally on its own. In that case you would also mask systemd-networkd, and use resolv.conf. Rather, your resolv.conf would say “generated by network manager” and the /run/systemd/resolve/resolv.conf no longer applies.
Is one better?
I have used both methods for dns. They both work reliably. Some like to only have one system manage networking, in that case mask systemd-resolved. Others do not care and leave systemd-resolved active. It makes no difference. Only thing is if you use systemd-resolved, you cannot edit resolv.conf directly like you can with pure network manager or say Wicd for example. In either case, you do not need a .network file in systemd either. But do not have both active at the same time otherwise strange things happen
Does your suggested config work in both, CLI and GUI?
If you are going with Network manager, these are usually the relevant networking files for config and such: the /etc/NetworkManager directory which has /NetworkManager.conf.
Using a client written in memory safe python is best. There was a whole debacle a few years ago where an obscure bash feature these clients relied on allowed remote code execution on a machine.
I’d rather we stayed away from systemd resolution and handled it differently but thanks for the informative post otherwise.
@Patrick,
Hi, yes it does work as cli; there is a set of commands that comes with the nm package called “nmcli” You would go to terminal and type nmcli connection show to see everything configured, uuid, name, etc. You can edit, remove, or create a new connection. The style is similar to: nmcli connection add [COMMON_OPTIONS] [TYPE_SPECIFIC] [OPTIONS] [IP_OPTIONS]. I must say I was very surprised my self b/c after using nm for years, I really had no idea how functional it can be from commandline.
With regard to the drop in file, NM has a conf.d folder built in the /etc/NetworkManager directory. Right now, I put a small file in there that says to turn power-management off for example. Also a dispatcher.d folder where you can specify pre-up, pre-down info. I have not needed to experiment much with specialized configs, but I know you can write scripts in bash and place then in either conf.d or dispatcher.d according to what you needed to do.
Importantly, this is something that I have on a separate distro, not Kicksecure, but nm can of course be downloaded and used on Debian with no difficulty. It works quite well with Gnome. Setting it up with the gui is really a breeze.
I will admit I have literally zero experience with dns-crypt, so am not too sure about how to set it up. But, the kicksecure networking that you linked on github would probably be able to put its config files in the main /etc/NetworkManager folder. They supply a default folder for dnsmasq that lives there, so why not dns-crypt? It would probably just be a matter of letting nm know that dns-crypt controls the dns now. @HulaHoop, I agree with you sir; I too wish to avoid involving systemd in networking. Fortunately, both systemd-networkd and systemd-resolved can easily be first disabled and then masked.
I would be happy to offer any guidance or help on setting up nm if needed
Python would be great; I remember the incident you’re referring to. That’s the whole thing with the command injection vuln where a dhcp response was faked and the result was gained root privelege, or overflows and other manner of havoc.
“By default NetworkManager uses its internal DHCP client. The internal DHCPv4 plugin is based on the nettools’ n-dhcp4 library, while the internal DHCPv6 plugin is made from code based on systemd-networkd.”
Question: is an additional package for DHCP really needed here?
For the security and privacy advantage is really the only reason. I read network-manager compatibility support for dhcpcanon has graduated from experimental before Buster was frozen.
Nm likes (for dhcp assignment) to call the /sbin/dhclient/ script. Then, that script runs and in turn tells nm-dhcp-helper which takes over from there. My question is would it be hard to tell dhcpanon to deal with nm directly or would it take the place of dhclient and then communicate with nm-dhcp-helper?
Preferably, none but this wouldn’t be the most usable. DHCP is unencrypted and unauthenticated, making it vulnerable to MITM attacks. It can also leak certain identifiers like the hostname but dhcpcanon should solve these.
Tails has an issue on using dhcpcanon but it has no activity.
We could maybe create a script to automatically set up a static IP but this would be far more error-prone than DHCP.
Not sure that’s doable. Gets a lot more complex. An either DHCP or static wizard implementation would require a script. Generating the configuration files using a script makes the whole thing rather functional. While a DHCP implementation could be purely declarative (only config files).
Related to Focus on low-effort maintainability.
Then also CLI vs XFCE support. Must work in CLI somehow too. Think: server support. Using an ISO to install a server. In that case broken DHCP or any setup questions are even worse.
But it’s rather theoretic as we don’t even have a simple network manager / DHCP implementation yet, nobody yet signing up working on that, and missing other major parts such as kicksecure homepage, forums, iso, etc.