On 01/25/2015 06:59 AM, Paul Rogers wrote: >>> Putting the actual name of the script to be run in the SERVICE >>> variable opens up the possibility of running arbitrary code if the >>> interface config file can be compromised. Certainly that file >>> should be write protected, but even so this just expands the "attack >>> surface". It should at least have mode 600 root:root, and probably >>> even be in an "invisible" directory. >> >> It is 644 root:root now. I don't see how the read bits change >> anything. > > "The curious thing was the dog in the night." > "But, Holmes, the dog did nothing in the night." > "That was the curious thing." > > "Out of sight, out of mind." If someone can't see how it works > it's that much harder to see a possible attack on its weakness. > It's the other side of the "social engineering" coin that is so > effective in phishing.
Well, that's bullshit in my opinion. Any attacker can go to linuxfromscratch and look at the sources anyway, so obscurity buys you nothing at all. It's not as if linuxfromscratch was a closed-source project, is it? > >>> The service directory should probably also be invisible. >> >> Security by obscurity is not really effective. > > True enough, it doesn't *create* security. Nevertheless, camouflage is > an effective tactic in warfare, even hunting. > Again, all that stuff is open source, so it is visible anyways. >>> Arguably, even if it would be harder to maintain, that "service" >>> should probably be isolated by matching it in a case statement in >>> ifup, then ifup would have the actual script's path and parameters > > My rules: I changed it to use a case statement. I accept the > responsibility for changing it if I add a new service. > >>> internally. "Ease of use" has opened up many holes. This looks >>> like one. >> >> Your concerns seem to be about situations where a hacker already >> has root. > > Not at all. The fact remains, whatever is in the SERVICE variable will > be executed with root priveleges by init, however it got that way, > whatever damage it may wreak, and it's not necessary. > -- decentral.ch - IT Stuff Tim Tassonis Dennlerstasse 36 8047 Zürich [email protected] +41 79 229 36 17 -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
