Slashdot Mirror
Sloppy File Permissions Make Red Star OS Vulnerable
An anonymous reader writes: Red Star OS Desktop 3.0, the official Linux distro of North Korea, which recently found its way onto torrents and various download sites in form of an ISO image, is interesting for a number of reasons, including its attempt to look like commercial operating systems (currently OS X, earlier versions mimicked the Windows GUI). Hackers are also poking Red Star for security vulnerabilities. An pseudonymous researcher noted in a post to the Open Source Software Security (oss-sec) mailing list, that the OS has one significant security hole: Red Star 3.0 ships with a world-writeable udev rule file /etc/udev/rules.d/85-hplj10xx.rules (originally designed for HP LaserJet 1000 series printers) which can be modified to include RUN+= arguments executing arbitrary commands as root by Udev. In the post he also mentions how the older Red Star 2.0 shipped with another schoolboy mistake: /etc/rc.d/rc.sysinit was world-writeable.
Whenever I see devs take the stupid shortcut of "chmod 777" I wonder what is the brain drain for these "professionals" that they can't figure out how to enable make use of "chown root:admin" and then "chmod g+x", or whatever's the appropriate level of permissions for the task at hand.
How can developers be so lazy and so security naive? It's like using signal lights when driving. Just do it because it makes for good habits.
blog
Some alternatives sound nice but fail horrificly when the come in contact with people, especially the ones that let any people within a group grant access to others with zero oversight. Within a short period of time with such a "everyone can grant or deny access" scheme you end up with almost everything wide open and occasional calls when the paranoid have locked themselves and everyone else out of something and forgotten the password - and it's typically something business critical (as in people need to get to it so they can do their job) but not actually sensitive with only a few people normally allowed to get to it. So the superuser is locked out - what do you do? Well such things are normally not well thought out in any way at all so you crack in with ease, especially since you have full access to the hardware, which kind of makes the whole idea of having permissions that lock out the superuser look pretty silly doesn't it?
So while user/group/all looks simplistic and kind of sucks in some cases there's nothing else that's really shown itself to be good enough to gain traction apart from where mandated by a vendor.
Saw that - first day at a new site and the developer that had been looking after things rebooted both the primary domain server and secondary domain server at the same time in the middle of a working day, for some trivial fix that didn't need to be done immediately and probably didn't even need a reboot. Of course they were also serving most of the files and all the printing as well. It's a mindset not a skillset. He knew what would happen but there was a fix for something so it had to be done NOW so he could get it out of the way without having to worry about it later. Consequences didn't matter, after all the new guy was there to take all the angry phone calls.
The old POSIX compliant user-group-others model does have some limitations. The non-root user can't arbitrarily add another individual user to have access or deny access, and only root users or site admins have access to create new groups. In the older systems, such as in UNIX's /etc/group and /etc/passwd, groups cannot contain other groups directly and there's a maximum line length on the number of characters in the "/etc/group" line. This gets quite awkward if you have hundreds of members of a group, or want to be able to say "all members of this group, *except* this one account, should have access to this". It means you have to add a new group and reset all files to owned and managed by that group: it can become painful to administer.
When compared to the obscure rat's nest of ownership in NTFS, however, I can see why the old POSIX ACL's have remained in use. And let's make not be confused, in the Windows world it is _extremely_ common to leave file ownership profoundly broken.