Posts Tagged ‘Linux’
Naive approaches to computer security have long been a thorn in my side, starting with the long lasting Windows assumption of a single user and user account on a system. (Originally explicit in that no second user account or user control was available; in the last ten-or-so-years in the form that the standard case is one user and one user only—who if at all possible should only ever work with one account.)
Unfortunately, Linux has also taken a turn for the worse over the years, often taken extremely naive approaches, prioritizing the convenience of the inexperienced user over security*, and opening holes that even a highly proficient user is often unaware of—and with more and more holes as time goes by.
*With the dual effect that those who want security have to put in a load of work (and likely still fail) and that many users are not aware of how poor their security is. Notably, the naive users might be pleased about the convenience—but they too are victims of the poor security. I would even argue that because they are naive, there is a greater obligation to protect them through implementing strong default security.
A prime example is the default file permissions (umask), which on most modern systems are set so that anyone can read the files of everyone else… This is so obviously wrong and idiotic that whoever is responsible should be taken out and shot. The obvious correct default behavior, and what matches the reasonable intent on almost all systems, are permissions where either only the owner is allowed to read a file or only the owner and the members of the files “group”*. One of the first things I do with a new installation is to restrict the default file permissions to owner only—if something else is needed for a specific file, I override the default.
*The standard file permissions on Unix-like systems divide the world into the owner, the group, and everyone else. By assigning users to a group, they can be given different access to certain files than “everyone else”, without being the owner.
This misconfiguration is particularly dangerous because it is unexpected, it is often only discovered when it is (potentially) to late, and it requires an over-average amount of knowledge to correct*.
*It is not enough to simply change the default setting: Each and every file that has already been created with that setting must have its individual setting corrected.
Another particularly annoying and dangerous problem is demonstrated by utterly conceptually flawed tools like sudo, pkexec, and polkit: Much like the execution controls in Windows, they assume that a user has a varying amount of rights to do things depending on how he does them. (E.g. through calling a command with or without sudo, or through giving or not giving a password to polkit.) While these tools are intended to increase security, they instead open up ridiculous security holes, and increase the likelihood both of users being given rights that the admins never intended them to have and of hostiles being able to achieve “privilege escalation”*.
*Roughly, an attacker starting with a certain set of rights that do not pose a danger and tricking the system into giving him more rights until he does pose a danger. This is a central part of cracking a computer system.
Consider sudo: The intention of sudo is that when a user executes the command X as “sudo X” (instead of just “X”), it is as if root (the main admin user) executed the same command. Now, what commands are allowed to “sudo” for a certain user is configurable, but this configuration can be a bitch. Take something as harmless as an editor: If the user can “sudo” the editor, he can now change system files, manipulate the password storage, read documents that should be secret, … The system is effectively an open book that a skilled cracker can exploit and infiltrate as he sees fit. OK, so we do not allow editors (and a number of more obvious things like command shells, commands to delete files, and the like). Now what about all the other applications that are not editors but still have the ability to execute editors or have the ability to even just save a file? What about those that can execute commands (e.g. through a “shell escape”—a very common mechanism on Unix-like systems)? They too must be ruled out. Etc. But here is the real devilry: How do we find out what commands have what abilities? This is a virtually impossible task, with many nasty surprises—e.g. that the standard pager (“less”; seemingly only intended to view files) has the ability to launch an editor… The only chance is to reduce the “sudoable” commands to an absolute minimum, carefully verify that minimum, and (more likely than not) conclude that the users now do not receive the convenience that sudo was intended to give them.
The task of configuring sudo is made the harder because most Linux distributions appear to work on the assumption that any system is a single user system (as with Windows above)—and cram down whatever gives the user convenience in the corresponding configuration. Looking at the configuration file /etc/sudoers on my current system*, I find e.g.
*No worries: While the configuration file is still there, the actual sudo program has been removed.
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
The comment line says it all.
Now, a good admin would not assigns the group “sudo” to just anyone and would use far more granular settings to give individual users what they need. However, not all admins* are good and this approach practically invites the admin to be lazy and assign rights carelessly. To boot, this makes it ease for the Linux distribution to screw up, because the consequences of a change become hard to predict, e.g. when default group assignments or default configuration entries are altered. In one horrendous case I heard of some months ago, the default configuration actually gave everyone, irrespective of group, the right to “sudo” anything, resulting in a system with no actual security anymore…
*Note that the admin is often quite, quite poor as an admin: Admins are not just found in big enterprises—the family member who takes care of the family’s computers is also an admin.
Others do truly stupid things, like https://help.ubuntu.com/community/Sudoers which gives an example of how to add an editor (!) to the configuration—and this in a section titled “Common Tasks”…
myuser ALL = (root) NOPASSWD:NOEXEC: /usr/bin/vim
This example lets the user “myuser” run as root the “vim” binary without a password, and without letting vim shell out (the :shell command).
Well, preventing “shell out” (more properly “shell escape”, one of the issues I mention above) is good, but obviously the idiot who wrote this has failed to understand that an editor is lethally dangerous too (cf. above). For instance, “sudo vim /etc/shadow” gives a malicious user the possibility to change the root password, after which he can trivially gain a root shell—without needing a “shell out”.
In contrast, the earlier approach was very sound: Either a user account had the right to do something or it did not—end of story. Usually, “did not” applied, when not dealing with the users own files. When more rights were needed to do a task the physical user had to log in with a new user account with more rights in the relevant area (and typically less in other areas!)—if he was trusted with such an account*. Yes, sudo can be more convenient, but that convenience is bought with a horrendous drop in security.
*If he was not trusted, then he correctly had no opportunity to do whatever he wanted to do.
The one saving grace of sudo is that it makes live a little safer for those who would otherwise take even greater risks in the name of convenience, through giving themselves dangerous rights all the time. This, however, is not a valid reason to make life that much less secure for the users who actually try to be secure and know how to handle themselves. This is like noting that condoms reduce pleasure and replacing condoms with some other mechanism which gives more pleasure—but does so at the price of not actually preventing pregnancy and disease transmission…
As a rule of thumb: If someone recommends that you use sudo, discount anything he says on security issues. This tool is simply one of the worst security ideas in the history of Linux.
I have seen some truly absurd cases, e.g. one nitwit who adamantly insisted that logging in as root on a terminal was very dangerous, but still threw sudos around willy-nilly. (While logging in as root is never entirely without danger, a terminal is the least dangerous place to do so, seeing that this reduces the risk of a snooper catching the password, removes the temptation of starting various GUI programs, and drastically reduces the risk of forgetting that one is using the root account and mistakenly doing something stupid.)
Excursion for the pros:
Those who know a little more about Unix security might see a major advantage of sudo in the reduced need for suid-ing programs. This might or might not have been an advantage at some point of time, but I have worked for years without using sudo and I have never needed to change anything in this regard. I conclude that what should work works, be it through appropriate group settings, daemons, or suid programs that are there irrespective of the presence of sudo. In addition, I am not convinced that suid programs, the potential dangers notwithstanding, are a greater evil than sudo, at least not after considering the relative likelihood of an admin doing some stupid—it is not just a question of what approach is the safer technically, but also of what approach gives us the better protection from human errors.
Last week, I was directed to a page wishing to prove that more than 1 % of all desktop users use Linuxe. Considering its approach of actually trying to get sufficiently many Linux users to announce themselves, this is a herculean task, which can benefit from a little help—like the inclusion in a few blogrolls.
I recommend any Linux user to drop by to increase the statistic.
(Note: An email address must be given. While the site looks legitimate overall, I recommend the precaution of using a disposable address.)
As I wrote in March, a jury ruled in favour of Novell in the fight against SCO, whose widely-considered-faulty claims had caused great costs and uncertainty for a number of other parties (including, obviously, Novell).
There was still some remaining uncertainty in theory (considering the overall situation and previous judgements, a practical problem was unlikely), because there were further “findings of facts” and various motions to be decided by the judge. As Groklaw now reportse:
Judge Ted Stewart has ruled for Novell and against SCO. Novell’s claim for declaratory judgment is granted; SCO’s claims for specific performance and breach of the implied covenant of good fair and fair dealings are denied. Also SCO’s motion for judgment as a matter of law or for a new trial: denied. SCO is entitled to waive, at its sole discretion, claims against IBM, Sequent and other SVRX licensees.
Maybe I should say cases closed. The door has slammed shut on the SCO litigation machine.
I recently wrote about the SCO vs. Novell trial, the verdict of which is now, with some delay, in:
A unanimous jury rejected SCO’s copyright claims, which likely means the end to this threat once and for all. Virtual champagne all around!
Of course, looking at the preceding decade, SCO has been harder to get rid of than Jason Voorhees; however, unlike Jason, it is not actually supernatural.
Right now, a trial of great importance is underway: The battle between Novell (the good guys) and SCO (the bad guys) concerning the rights to Unix. Unfortunately, most people seem to be entirely unaware of it.
Why is this battle so important?
In order to understand this, a brief overview is needed, and will be given below. By necessity, it will be an over-simplification: The story is extremely convoluted, involves many parties, and is stretched over a very long time. For those interested in more details, I recommend Wikipediaw; for those truly interested, there are enormous amounts of material present at Groklawe or, in German, Heisee.
Some forty years ago, the operating system Unix takes its first steps at AT&T. This little toddler is to grow into one of the dominating server and workstation operating systems for several decades—and to be the progenitor of both Linux and Mac OS X.
In the early nineties, AT&T sells the rights to Novell (the first of the combatants). In 1995, some of these rights are sold to SCO (confusingly, not the second combatant). Here however, we encounter the point of contention: Which rights, exactly?
Only in 2000 does the second combatant, then called Caldera, enter the arena by buying the Unix business of the original SCO. Not long thereafter, Caldera changes its name to SCO Group, in an effort to capitalize on the strong brand-name of the original SCO, which it has also bought. Meanwhile the original SCO departs from our tale.
Having had a few less than successful years, SCO looks for a solution to its money problems, and in 2002 it begins the dangerous gamble of claiming more extensive rights to Unix than it was acknowledged to have—and that Linux would contain significant portions of unlicensed Unix code. Calls for proof are raised; none is given.
In 2003, all hell breaks lose. A slew of law suits are started: SCO v. IBM, Red Hat v. SCO, SCO v. Novell, SCO v. AutoZone, SCO v. DaimlerChrysler. Claims and counter-claims are made, and litigation that lasts until at least 2010 ensues. SCO’s most noteworthy claim: IBM owns it one billion dollar (yes, billion) relating to its alleged and allegedly illicit use of intellectual property allegedly belonging to SCO. This amount was later increased to five billion… To make matters worse, this has the appearances of pilot case, with more to follow upon success.
The above paragraph has been revised for two errors since the original publishing:
When checking the numbers, I overlooked the increase to five billion dollars.
I claimed that even one billion was far more than SCO was every worth. While I still hold this statement to be true, it is technically wrong, seeing that Caldera had a market capitalization of more than that shortly after its IPO. That number, however and IMO, was severely hyped, did not reflect actual sales and prospects, and dwindled soon afterwards. (See also CNET on the IPOe or historical share-price informatione of SCO.)
Generally, I gathered most facts from a few timelines on the given links, without revisiting the case to a greater depth. (I followed the case with great interest in the early years, but with the passage of time…) Correspondingly, there may be other errors in detail—not, however, in the big picture.
In parallel, SCO tries to leverage its claims in other ways, e.g. by trying to bluff companies merely using Linux into purchasing “anti-dote” licenses as protection against potential law suits for larger amounts.
As time goes by, SCO becomes more and more focused on these lawsuits, seeing the rest of its business disappear. It is now in a do-or-die situation—win the jackpot in court or end up in bankruptcy. It has become a company effectively geared at just one thing—litigation.
Because SCO is never able to produce evidence, it has little success, often see its claims struck down by summary judgments, and only manages to stay above the water-line through injections of additional capital, including from Linux’, Unix’, and Apple’s archenemy—Microsoft. Those claims that are not struck down are often stayed awaiting one of the other cases, either SCO v. IBM or SCO v. Novell.
In the autumn of 2007, the issue seems to be concluded: A summary judgment falls, stating that Novell is the rightful owner of the relevant Unix rights, which pulls out the carpet from all other cases; and SCO is effectively bankrupt.
However, hanging by a thread and protected by Chapter 11, SCO manages to remain to in the fight—and in August 2009, an appeals court finds that parts of the summary judgment were premature and must be treated in a full trial. This trial is now underway, expected to be concluded in the coming week (knock on wood).
As should be clear even from this greatly simplified overview, the situation has been highly chaotic, and great stakes are involved. Those who dig into the sources given above will find more chaos yet, including many other examples of highly disputable behaviour on the part of SCO—and many cases of infighting and internal intrigues.
Now, why is it important that SCO lose this trial? Mainly, were SCO to win, it would set a dangerous precedent with regard to making legal claims bordering on the frivolous, extorting money by means of legal threats, and making grossly misleading accusations against other organisations: The justice system is abused often enough as it is—with a SCO victory, we could see a flood of lawsuits where failing companies try to ensure their survival by suing wealthier companies, possibly causing immense damage to third parties along the way. In addition, it is still conceivable that a SCO victory could do great damage to the companies and communities involved in developing Linux, and similar lawsuits against other members of the extended Unix family would not be inconceivable—and consider if Linux takes a severe hit at the same time as Apple is locked up in ten years of costly litigation: All of Gaul could well be conquered by the Redmonds this time.
Notably, while the probability that SCO will win sufficiently many battles is small, the stakes are sufficiently high that there is still reason to be nervous. In football terms: We may be a few minutes away from the end of the fourth quarter and have a two-touchdown lead—but the game is the Superbowl.
The issue of ObamaCare may be more important, but neither the OJ trial(s) nor the actual Superbowl holds a candle.