4 ms·

That blog has already been discussed various times on Hacker News. The author makes some questionable claims. A security issue is not good, but it's not remotel

by bkor 10y ago

That blog has already been discussed various times on Hacker News. The author makes some questionable claims. A security issue is not good, but it's not remotely executable, nor has any relation to being triggered via Twitter. Although this is clarified in the blog, the summary is very misleading. The same author also made a followup blog with even more strange arguments. Saying that systemd security features doesn't matter more or less because applications should be secure by themselves / do that on their own. I'd refrain from forming your opinion solely on blogposts such as these.

new299 10y ago
No I didn't form an opinion solely based on this blog. But it made me reconsider my opinion based on my own experience of systemd and the fact that it seems to be very much against the UNIX philosophy (I want a UNIX like system, in particular usecases at least). Did anyone actually think this was a remote exploit that could be triggered via twitter? I certainly was never under that impression.
- microcolonel 10y ago
  Please explain how: a) systemd violates "the UNIX philosophy". b) "the UNIX philosophy" applies to long-running processes. UNIX daemons have existed for a long time, and they have never been as single-purposed as the shell utilities; so arguably "the UNIX philosophy" doesn't have anything to say about daemons. Secondly, systemd's PID1 has basically only as much functionality in it as makes sense. If they move that functionality to another daemon, it'll be worse.
deleted 10y ago
[deleted]
winter_blue 10y ago
I read the whole blog post, and I didn't find anything I would disagree with, in it. In my opinion, he makes several good points. > even more strange arguments [...] because applications should be secure by themselves I'll quote him on this: "good programmers recognize the difficulty of writing bug-free software and understand the importance of designing software in a way that minimizes the likelihood of bugs or at least reduces their impact". Design and architectural choices including the choice of programming language have a high impact on the code quality and reliability (incl. security) of a system. No matter how good a programmer you are, there's just a lot additional mental overhead when using an unsafe language like C, as you have to always be on the watch-out for type-safety related bugs, and for memory safety (not accessing invalid references), memory leaks (and always free()ing), and bounds-checking stuff. To quote him further: "Go and Rust are compelling, safe languages for writing the type of systems software that has traditionally been written in C. Systemd is dangerous not only because it is introducing hundreds of thousands of lines of complex C code without any regard to longstanding security practices like privilege separation or fail-safe design" Forget to check array bounds just once, and you might have just created a new security vulnerability. You have to be perfect. Not make a single mistake. Run Valgrind and every code quality other tool, and you still could have missed something subtle. C is an inherently unsafe language, and a poor choice for new projects when alternatives like Rust and Go exist. The other problem is that one should try to avoid building giant monolithic systems. (I think) I read somewhere once that Linus Torvalds said that in hindsight not adopting a microkernel architecture was the biggest mistake he'd made. Quoting the author: "Systemd is far more than an init system: it is becoming a secondary operating system kernel, providing a log server, a device manager, a container manager, a login manager, a DHCP client, a DNS resolver, and an NTP client. These services are largely interdependent and provide non-standard interfaces for other applications to use. This makes any one component of systemd hard to replace, which will prevent more secure alternatives from gaining adoption in the future." A single PID 1 process shouldn't be doing a million things. Splitting up responsibilities into different specialized programs, running in their own processes would be the way to go. IPC overhead is not sufficiently large to justify creating one giant statically linked executable that does a million things. It's not the Unix philosophy either. > it's not remotely executable, nor has any relation to being triggered via Twitter Maybe he shouldn't have have used the word "tweet" in the title, but it's clear what he's talking about a few sentences in. And, what do you mean it's not remotely executable? Did you try running it? > I'd refrain from forming your opinion solely on blogposts such as these. The author backs up his claims by linking to specific bug-causing lines in GitHub. He makes several solid beautifully explained arguments. It couldn't be more well-written. How many blog posts claiming security holes link to specific lines of code? Your dismissal of his entire blog isn't justified.

by bkor 10y ago

new299 10y ago

No I didn't form an opinion solely based on this blog. But it made me reconsider my opinion based on my own experience of systemd and the fact that it seems to be very much against the UNIX philosophy (I want a UNIX like system, in particular usecases at least). Did anyone actually think this was a remote exploit that could be triggered via twitter? I certainly was never under that impression.

microcolonel 10y ago
Please explain how: a) systemd violates "the UNIX philosophy". b) "the UNIX philosophy" applies to long-running processes. UNIX daemons have existed for a long time, and they have never been as single-purposed as the shell utilities; so arguably "the UNIX philosophy" doesn't have anything to say about daemons. Secondly, systemd's PID1 has basically only as much functionality in it as makes sense. If they move that functionality to another daemon, it'll be worse.

deleted 10y ago

[deleted]

winter_blue 10y ago

I read the whole blog post, and I didn't find anything I would disagree with, in it. In my opinion, he makes several good points. > even more strange arguments [...] because applications should be secure by themselves I'll quote him on this: "good programmers recognize the difficulty of writing bug-free software and understand the importance of designing software in a way that minimizes the likelihood of bugs or at least reduces their impact". Design and architectural choices including the choice of programming language have a high impact on the code quality and reliability (incl. security) of a system. No matter how good a programmer you are, there's just a lot additional mental overhead when using an unsafe language like C, as you have to always be on the watch-out for type-safety related bugs, and for memory safety (not accessing invalid references), memory leaks (and always free()ing), and bounds-checking stuff. To quote him further: "Go and Rust are compelling, safe languages for writing the type of systems software that has traditionally been written in C. Systemd is dangerous not only because it is introducing hundreds of thousands of lines of complex C code without any regard to longstanding security practices like privilege separation or fail-safe design" Forget to check array bounds just once, and you might have just created a new security vulnerability. You have to be perfect. Not make a single mistake. Run Valgrind and every code quality other tool, and you still could have missed something subtle. C is an inherently unsafe language, and a poor choice for new projects when alternatives like Rust and Go exist. The other problem is that one should try to avoid building giant monolithic systems. (I think) I read somewhere once that Linus Torvalds said that in hindsight not adopting a microkernel architecture was the biggest mistake he'd made. Quoting the author: "Systemd is far more than an init system: it is becoming a secondary operating system kernel, providing a log server, a device manager, a container manager, a login manager, a DHCP client, a DNS resolver, and an NTP client. These services are largely interdependent and provide non-standard interfaces for other applications to use. This makes any one component of systemd hard to replace, which will prevent more secure alternatives from gaining adoption in the future." A single PID 1 process shouldn't be doing a million things. Splitting up responsibilities into different specialized programs, running in their own processes would be the way to go. IPC overhead is not sufficiently large to justify creating one giant statically linked executable that does a million things. It's not the Unix philosophy either. > it's not remotely executable, nor has any relation to being triggered via Twitter Maybe he shouldn't have have used the word "tweet" in the title, but it's clear what he's talking about a few sentences in. And, what do you mean it's not remotely executable? Did you try running it? > I'd refrain from forming your opinion solely on blogposts such as these. The author backs up his claims by linking to specific bug-causing lines in GitHub. He makes several solid beautifully explained arguments. It couldn't be more well-written. How many blog posts claiming security holes link to specific lines of code? Your dismissal of his entire blog isn't justified.