5 ms·

one more reason for networking done by network-manager or networkd (systemd) instead of bash scripts

kbar13 12y ago
that's some straw man you got there. Just because bash is vulnerable in this case doesn't mean that networkd/network-manager will never be vulnerable.
- danielweber 12y ago
  Does NetworkManager completely obviate the need for the DHCP binary to call shell scripts? Those scripts often exist because if the sysadmin needs something special to happen on DHCP, this is where he sets it. It's not "DHCP scripts get run by/are shell scripts," it's "DHCP binaries are prepared to call out to external scripts." I've had to write these shell scripts (using ksh, since OpenBSD, so those are safe).
  - Maken 12y ago
    Well, Network Manager for starters is a binary and not a shell script like the dhclient-script.
    - danielweber 12y ago
      dhclient is a binary on Linux and OpenBSD. It calls shell scripts, because, like I said in the comment you replied to, sometimes sysadmins need very specific things to happen when the machine gets a DHCP lease.
    - dfc 12y ago
      Network manager depends on "the dhclient-script." > A variety of other system services are used by NetworkManager > to provide network functionality wpasupplicant for wireless > connections and 8021x wired connections pppd for PPP and > mobile broadband connections DHCP clients for dynamic IP > addressing http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/README#n51 http://cgit.freedesktop.org/NetworkManager/NetworkManager/tr...
Sanddancer 12y ago
NetworkManager's had vulnerabilities over the years ( http://www.cvedetails.com/product/5634/Gnome-Networkmanager.html?vendor_id=283 http://www.cvedetails.com/product/5634/Gnome-Networkmanager.... ), as has systemd. Stating this as a reason to switch is ridiculous. One can easily switch to a much more audited, secure scripting environment, such as ksh, and still have all the power scripting brings.
- muyuu 12y ago
  Not saying I agree with GP, but "the power scripting brings" can be part of the problem. Scripting is used as a means to execute arbitrary commands on a single level privilege (that of the user hooking the scripts, very often root or some high-privilege user) as opposed to a limited set of application-specific functionality. This adds a whole level of complexity to the system, which in security terms is typically the kind of thing that will give you trouble.
  - azernik 12y ago
    Agreed. When in security classes we were taught to use e.g. execve() instead of system(), it wasn't because shells were thought of as particularly vulnerable. You just want to use a tool that has the minimum possible feature set, so you can be sure that no one malicious will be able to trick you into using even correctly-functioning features (e.g. through shell injection). Sort of a special case of the principle of minimum privilege, when applied to the feature set of your tools.
  - zobzu 12y ago
    pretty much. scripting envs are extremely flexible and powerful, thus very prone to such issues. thats why you dont give user input to shells unless you want the user to have the full shell access. environment included.
Igglyboo 12y ago
yes because it is impossible for network-manager/networkd/systemd to have vulnerabilities
beedogs 12y ago
So this would be the first reason, then?
MertsA 12y ago
NetworkManager still mucks around in /etc/sysconfig/network-scripts and is probably a lot more complicated than it needs to be. I'd like to think that networkd is a better approach with a smaller attack surface but also right now networkd doesn't have the maturity or usage of NetworkManager or crappy network scripts so it would be unwise to suggest that networkd is more secure because of that. Especially when you lump in NetworkManager as another alternative that's done better, if anything I'd rather have no NetworkManager or networkd than have to use NetworkManager on something other than a laptop as random bugs in NetworkManager have personally bit me before. That being said the design of networkd looks very nice indeed and against my better judgement I'm even running it in something that you could almost consider production.
SixSigma 12y ago
Or not Linux at all.

that's some straw man you got there. Just because bash is vulnerable in this case doesn't mean that networkd/network-manager will never be vulnerable.

danielweber 12y ago
Does NetworkManager completely obviate the need for the DHCP binary to call shell scripts? Those scripts often exist because if the sysadmin needs something special to happen on DHCP, this is where he sets it. It's not "DHCP scripts get run by/are shell scripts," it's "DHCP binaries are prepared to call out to external scripts." I've had to write these shell scripts (using ksh, since OpenBSD, so those are safe).
- Maken 12y ago
  Well, Network Manager for starters is a binary and not a shell script like the dhclient-script.
  - danielweber 12y ago
    dhclient is a binary on Linux and OpenBSD. It calls shell scripts, because, like I said in the comment you replied to, sometimes sysadmins need very specific things to happen when the machine gets a DHCP lease.
  - dfc 12y ago
    Network manager depends on "the dhclient-script." > A variety of other system services are used by NetworkManager > to provide network functionality wpasupplicant for wireless > connections and 8021x wired connections pppd for PPP and > mobile broadband connections DHCP clients for dynamic IP > addressing http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/README#n51 http://cgit.freedesktop.org/NetworkManager/NetworkManager/tr...

Sanddancer 12y ago

NetworkManager's had vulnerabilities over the years ( http://www.cvedetails.com/product/5634/Gnome-Networkmanager.html?vendor_id=283 http://www.cvedetails.com/product/5634/Gnome-Networkmanager.... ), as has systemd. Stating this as a reason to switch is ridiculous. One can easily switch to a much more audited, secure scripting environment, such as ksh, and still have all the power scripting brings.

muyuu 12y ago
Not saying I agree with GP, but "the power scripting brings" can be part of the problem. Scripting is used as a means to execute arbitrary commands on a single level privilege (that of the user hooking the scripts, very often root or some high-privilege user) as opposed to a limited set of application-specific functionality. This adds a whole level of complexity to the system, which in security terms is typically the kind of thing that will give you trouble.
- azernik 12y ago
  Agreed. When in security classes we were taught to use e.g. execve() instead of system(), it wasn't because shells were thought of as particularly vulnerable. You just want to use a tool that has the minimum possible feature set, so you can be sure that no one malicious will be able to trick you into using even correctly-functioning features (e.g. through shell injection). Sort of a special case of the principle of minimum privilege, when applied to the feature set of your tools.
- zobzu 12y ago
  pretty much. scripting envs are extremely flexible and powerful, thus very prone to such issues. thats why you dont give user input to shells unless you want the user to have the full shell access. environment included.

Igglyboo 12y ago

yes because it is impossible for network-manager/networkd/systemd to have vulnerabilities

beedogs 12y ago

So this would be the first reason, then?

MertsA 12y ago

NetworkManager still mucks around in /etc/sysconfig/network-scripts and is probably a lot more complicated than it needs to be. I'd like to think that networkd is a better approach with a smaller attack surface but also right now networkd doesn't have the maturity or usage of NetworkManager or crappy network scripts so it would be unwise to suggest that networkd is more secure because of that. Especially when you lump in NetworkManager as another alternative that's done better, if anything I'd rather have no NetworkManager or networkd than have to use NetworkManager on something other than a laptop as random bugs in NetworkManager have personally bit me before. That being said the design of networkd looks very nice indeed and against my better judgement I'm even running it in something that you could almost consider production.

SixSigma 12y ago

Or not Linux at all.