etbe - Russell Coker

Should Passwords Expire?

It’s widely regarded that passwords should be changed regularly. The Australian government declared last week the “National Cyber Security Awareness Week” [1] and has published a list of tips for online security which includes “Get a stronger password and change it at least twice a year“.

Can a Password be Semi-Public?

Generally I think of a password as being either secret or broken. If a password is known to someone other than the sysadmin and the user who is authorised to use the account in question then you have potentially already lost all your secret data. If a password is disclosed to an unauthorised person on one occasion then merely changing the password is not going to do any good unless the root cause is addressed, otherwise another anothorised person will probably get the password at some future time.

Hitachi has published a good document covering many issues related to password management [2]. I think it does a reasonable job of making sysadmins aware of some of the issues but there are some things I disagree with. I think it should be used as a list of issues to consider rather than a list of answers. The Hitachi document lists a number of ways that passwords may be compromised and suggests changing them every 60 to 90 days to limit the use of stolen passwords. This seems to imply that a password is something that’s value slowly degrades over time as it’s increasingly exposed.

I think that the right thing to do is to change a password if you suspect that it has been compromised. There’s not much benefit in having a password if it’s going to be known by unauthorised people for 89 days before being changed!

Fundamentally a password is something that can have it’s value rapidly drop to zero without warning. It doesn’t wear out.

Why are terms such as Three Months used for Maximum Password Ages?

The Hitachi document gives some calculations on the probability of a brute-force attack succeeding against a random password with 90 days of attacking at a rate of 100 attempts per second [2]. I think that if a service is run by someone who wouldn’t notice the load of 100 attempts per second then you have bigger security problems than the possibility of passwords being subject to brute-force attacks. Also it’s not uncommon to have policies to lock accounts after as few as three failed login attempts.

Rumor has it that in the early days of computing when the hashed password data was world readable someone calculated that more than 3 months of CPU time on a big computer would be needed to obtain a password by brute-force. But since then the power of individual CPUs has increased dramatically, computers have become cheap enough that anyone can easily gain legal access to dozens of systems and illegal access to a million systems, and it has become a design feature in every OS that hashed passwords are not readable by general users. So the limiting factor is to what degree the server restricts the frequency of password guesses.

I don’t think that specifying the minimum password length and maximum password age based on the fraction of the key space that could be subject to a brute-force attack makes sense.

I don’t think that any attempt to make an industry-wide standard for the frequency of password changes (as the government is trying to do) makes sense.

Can there be a Delay between a Password being Compromised and being Used by an Attacker?

Hypothetically speaking, if a password was likely to be compromised (EG by having the paper it was written on lost or stored insecurely) for some time before an attacker exploited it, then if the password was changed during that time period it could solve the problem. For example when a company moves office there is the possibility of notepaper with passwords to be lost. So if the sysadmin caused every user password to expire at the time of the move then a hostile party would be unable to gain access.

Another possibility is the theft of backup tapes that contain the list of unencrypted passwords. If users change their passwords every three months then the theft of some four month old backup tapes will be less of a problem.

Another possibility concerns the resale of old computers, phones, and other devices that may contain passwords. A reasonably intelligent user won’t sell their old hardware as soon as the replacement device arrives, they will want to use the new device for some time to ensure that it works correctly. If passwords expire during this trial period with the new device then passwords stored in the old device won’t have any value. The down-side to this idea is that people probably sell their old gear fairly quickly and making passwords expire every two weeks would not be accepted well by the users.

It seems to me that having bulk password changes (all passwords for one user or for one company) based on circumstances that lead to potential insecurity would do more good than changing passwords at a fixed schedule.

How are Passwords typically Compromised?

Dinei Florêncio and Cormac Herley of Microsoft Research and Baris Coskun of Brooklyn Polytechnic University wrote a paper titled “Do Strong Web Passwords Accomplish Anything?” [3] which discusses this issue. The first thing that they note is that nowadays passwords are most commonly compromised by phishing and keylogging. In those cases passwords are typically used shortly after they are stolen and the strength of a password never does any good. That paper suggests that banks should use stronger user-names rather than stronger passwords to combat the threat of bulk brute-force attacks.

Can a Password Last Forever?

If a password is entered in a secure manner, authenticated by a secure server, and all network links are encrypted or physically protected then there should never be a need to change it.

Of course nothing is perfectly secure, so for some things with minimal short-term value or which can be used without anyone noticing there is a benefit in changing the password. But in the case of Internet banking if a hostile party gets your login details then you will probably know about it in a few days when the bank calls you about the unusual transactions from foreign countries – long before a 90 day password change schedule would have done any good.

Maybe one of the issues determining whether a password should be changed regularly is whether an attacker could use long-term read-only access to gain some benefit. Being able to read all the email someone received for a year could be a significant benefit if that person was a public figure, and there’s usually no way for an ISP customer to know that someone else is downloading all their mail via POP or IMAP.

Should a Password be the only Authentication Method?

It is generally agreed that an authenitcation method should ideally involve something you have plus something you know. That means a password and a physical device such as a smart card, token with a changing sequential password, or a key such as a Yubikey [4]. If the physical device can’t be cloned (through some combination of technical difficulty and physical access control) then it significantly improves security. When a physical device is used the purpose of the password is merely to stop someone who steals the physical device from being immediately exploit everything – the password only has to be strong enough to keep the accounts secure until a new token can be issued.

The combination of something you have and something you know is very strong. Having a physical token stored on the desk next to the PC that is used for logging in provides a significant benefit, then an attacker needs to break in to the house and can’t sniff the password by compromising the PC remotely.

Conclusion

In all aspects of security you need to consider what threats you face. If an attacker is likely to launch an immediate noisy attack (such as transferring the maximum funds out of an Internet banking account) then changing the password regularly won’t do any good. If a subtle long-term attack is expected then changing the password can do a lot of good – but a physical token is the ideal if the account is valuable enough.

But to put things in to perspective, it’s technically possible to use a mobile phone camera at close range (or a SLR with a big lens at long range) to take a photo of keys that allow reproducing them. But this hasn’t stopped people from carrying their house keys in an obvious manner that permits photography or leaving them on their desk at work. Also I’ve never heard of anyone routinely changing the door locks in case a hostile party might have got a key – although I’m sure that such practices are common in highly secure locations. Few people even take their house keys off the key-ring when they have their car serviced!

Defense in Depth and Sudo – when using sudo can increase security and when it can’t.
Logging Shell Commands – how to log what the sysadmin does and what benefits that provides you, it doesn’t help if the sysadmin is hostile.
Logging in as Root – should you login directly as root?

Defense in Depth and Sudo

My blog post about logging in as root and whether sudo provides any benefit [1] got some interest on Redit. In the Reddit comments on my post [2] there are a lot of strange things. One interesting comment was to suggest that logging in as non-root provided “defense in depth”.

The NSA is credited with inventing the term “Defense in Depth” as applied to the computer industry, they have a PDF that gives an overview of the concept [3]. It seems that Defense in Depth is all about having multiple different layers of security, firewalls, IDS/IPS, passwords, PKI, etc. Entering the same password twice (once to login and once to run sudo – which seems to be a fairly typical configuration of sudo) hardly seems to count.

Can using sudo provide Defense in Depth benefits?

With a typical configuration the use of sudo provides no real protection. The user either enters their own password or the root password to gain full root access, in either case the attacker can exploit their session and get the password. A session exploit can be easily arranged by creating a shell function or alias that makes sudo run something else (such as using netcat to send the password out over the network).

One way of making this sort of attack more difficult is to make root own the user home directory, files such as ~/.login that are used by the user shell, the ~/.ssh directory and the ~/.ssh/authorized_keys file. This way a hostile party can’t change the configuration, so a successful attack has to involve a long running process that uses ptrace to intercept the shell and divert an attempt to run sudo.

If the non-root user is prevented from using ptrace then things start to become a little more difficult for the attacker. In some quick tests I was able to capture about half the data through messing with /proc/X/fd/0 and /proc/X/fd/1 for a target process, but it seems that it would be difficult to get an entire password that way. To disable ptrace you could compile a kernel without ptrace support, use a SE Linux policy that prevents prevent ptrace access for the sessions in question, or make the user’s shell SETGID.

If the root account and the account used for su or sudo use different authentication methods, where the options include ssh authorized keys, password, and security token (maybe both password and token for the root account) then it does seem that it would provide some Defense in Depth benefits.

sudo can be used to only permit executing certain commands. While this is a real security benefit it doesn’t allow full sysadmin work, merely delegating some portions of operations to people who don’t have full sysadmin rights. As someone needs to have full access to fix any problem that might occur on the machine someone needs to have access to run any command as root. So while sudo is great for providing limited administrative access to certain junior people, it’s not going to stop an attack on a member of the sysadmin team.

Conclusion

In a typical sudo configuration the non-root account is configured in a default Unix manner (with the user having ownership of their home directory). The user who logs in to that account controls it’s environment through .login and other scripts, so sudo doesn’t gain anything.

In a typical configuration ptrace is enabled so even if the critical environment files can’t be modified by a hostile party they can get the same result through ptrace. Admittedly using a SETGID shell is not going to be difficult to implement after you have changed the ownership of the home directory.

If you have a configuration where ptrace is not available and the non-root user can’t modify their own profile files then it starts to become difficult for an attacker. If root authentication requires using a security token such that every login uses a different code and the code expires rapidly then it becomes even more difficult for an attacker.

But for all configurations that are close to the default for every OS that I’ve ever used none of these conditions hold. Also none of those conditions held for any of the systems I’ve been employed to use which were configured to require su or sudo for root access.

As it seems that most sudo configurations don’t provide any extra security, and that auditing the actions of the sysadmin can be better done in other ways (such as the Bash 4.1 syslog feature) [4] it seems that for the vast majority of systems sudo doesn’t provide a benefit.

The fact that sudo could provide a benefit if configured in a way that is quite different to all the defaults and the ways that it is typically used is worth noting. I’m not going to argue with anyone who wants to configure their systems in such a manner and who believes that they need to do so. But anyone who thinks that sudo is the only way to go because the Ubuntu default configuration does it really needs to investigate the issues. Remember that blind faith in the security choices of other people can be a security problem.

Links June 2010

Seth Berkley gave an interesting TED talk about developing vaccines against the HIV and Influenza viruses [1]. The part I found most interesting was the description of how vaccines against viruses are currently developed using eggs and how they plan to use bacteria instead for faster and cheaper production. One of the problems with using eggs is that if the chickens catch the disease and die then you can’t make a vaccine.

Aigars Mahinovs wrote a really good review of Microsoft Azure and compared it to Amazon EC2 [2]. It didn’t surprise me that Azure compared poorly to the competition.

Johanna Blakley gave an insightful TED talk about IP lessons from the fashion industry [3]. She explained how an entire lack of IP protection other than trademark law was an essential part of the success of the fashion industry. She also compared the profits in various industries and showed that industries with little or no IP protection involve vastly larger amounts of money than industries with strong IP protection.

Lisa D wrote an insightful post about whether Autism Spectrum Disorders (such as Asperger Syndrome) should be considered to be disabilities [4]. I don’t entirely agree with her, but she makes some really good points.

Sharmeen Obaid-Chinoy gave an interesting TED talk about the way the Taliban train young children to become suicide bombers [5]. Apparently the Taliban prey on large poor families, sometimes paying the parents for taking children away to “school”. At the Taliban schools the children are beaten, treated poorly, and taught theology by liars who will say whatever it takes to get a result. Then after being brain-washed they are sent out to die.

Wired has an interesting article about Charles Komanoffâ€™s research into New York traffic problems [6]. He aims to track all the economic externalities of traffic patterns and determine incentives to encourage people to do things that impose less costs on the general economy. His suggestions include making all bus travel free as the externality of the time spent collecting fares is greater than the fare revenue. It’s a really interesting article, his research methods should be implemented when analysing traffic in all large cities, and many of his solutions can be implemented right now without further analysis – such as free buses and variable ticket pricing according to the time of day.

William Li gave an interesting TED talk about starving cancer by preventing new blood vessels from growing to feed it [7]. Drugs to do this have been shown to increase the life expectancy of cancer patients by more than 100% on average. Also autopsies of people who died in car accidents show that half the women in their 40’s had breast cancer and half the men in their 50’s prostate cancer but those cancers didn’t grow due to a natural lack of blood supply, so the aim here is to merely promote what naturally happens in terms of regulating cancers and preventing them from growing larger than 0.5mm^3. There are a number of foods that prevent blood vessels growing to cancers which includes dark chocolate! ;) Also drugs which prevent blood vessel growth also prevent obesity, I always thought that eating chocolate all the time prevented me from getting fat due to the central nervous system stimulants that kept me active…

Graham Hill gave an inspiring TED talk about becoming a weekday vegetarian [8]. Instead of making a commitment to being always vegetarian he’s just mostly vegetarian (only eating meat on Sundays). He saves most of the environmental cost and doesn’t feel guilty if he ever misses a day. It’s an interesting concept.

Cory Doctorow wrote an insightful article for the Guardian about the phrase “Information Wants To Be Free [9]. He points out that really it’s people who want to be free from the tyranny that is being imposed on us in the name of anti-piracy measures. He also points out that it’s a useful straw-man for the MAFIAA to use when claiming that we are all pirates.

The Atlantic has an interesting article about the way that Google is working to save journalistic news [10].

Adam Sadowsky gave an interesting TED talk about creating a Rube Goldberg machine for the OK Go video “This Too Shall Pass” [11]. At the end of the talk they include a 640*480 resolution copy of the music video.

Brian Cox gave an interesting TED talk advocating increased government spending on scientific research [12]. Among other things he pointed out that the best research indicates that the amount of money the US government invested in the Apollo program was returned 14* to the US economy due to exports of new American products that were based on that research. It’s surprising that any justification other than the return on investment for the Apollo program is needed!

Moot gave an interesting TED talk about Anonymity [13]. I don’t think that he made a good case for anonymity, he cited one person being identified and arrested for animal cruelty due to the efforts of 4chan people and also the campaign against the Cult of Scientology (which has not been very successful so far).

Rory Sutherland gave an intriguing TED talk titled “Sweat the Small Stuff” [14]. He describes how small cheap changes can often provide greater benefits than huge expensive changes and advocates corporations having a Chief Detail Officer to take charge of identifying and implementing such changes.

TED Hosted an interesting debate between pro and anti nuclear campaigners [15]. They agreed that global warming is a significant imminent problem but disagree on what methods should be implemented to solve it.

Logging Shell Commands

In response to my previous post about logging in directly as root [1] it was suggested that using sudo is the only way to log the commands that are entered as root. One reason for doing this is if you don’t trust the people who are granted root access and you want to log all commands to a remote server that is run by different people. I wonder whether it is really possible to run systems with untrusted sysadmins, if someone can apply patches etc then they can surely install a trojan and then wait a while before activating it to make things more difficult for anyone who is analysing the logs.

One of the many issues is that even the restricted version of vim permits the :r and :w commands, so one could start vim from sudo with an innocuous file as the target of the edit operation and then read and write some critical file such as /etc/shadow. I expect that someone has written an editor which has a restricted mode that doesn’t allow reading/writing files other than the one specified on the command-line, and if not it surely wouldn’t be difficult to patch vim (or your favorite editor) to have such a mode of operation. But there are always other programs that can access files other than the ones specified on their command-line. It seems that using the auditctl interface to log access to certain critical files (EG read access to /etc/shadow and write access to everything under /etc, /bin, /sbin, and /usr) would be a necessary part of an effective auditing strategy and that sudo would only comprise a small part of a useful configuration.

There are other viable ways of logging everything that is done as root which offer benefits over sudo.

Ways of Logging Shell Commands

The Korn shell supports doing all the logging you might desire as part of a shell function [2].

Bash can have a similar shell function to do the logging, but when a command is entered the previous command is logged [3], this means that any single bash command that unsets this will never be logged. It might be possible to solve this if you know more about Bash than I do. I wonder if the Korn shell function has the same issue. This is still probably useful for some situations when you want to track what honorable sysadmins do, but of little benefit for tracking hostile sysadmins – (tracking hostile sysadmins is actually possible).

You can put code in a file such as /etc/bash.bash_logout to log the commands elsewhere, but even trivial things such as “kill -9 $$” can defeat that so it’s only useful when the sysadmin is trusted.

The Sudoshell project exists to log all data that is entered in a shell [3]. One deficiency of this for the people who don’t trust the root user is that it logs the data to files on disk, but it shouldn’t be difficult to rewrite sudoscriptd to write directly to another machine over the network. Also one benefit of this for auditing is that it captures all the output of the commands as well (which can be a little inconvenient to decipher when curses programs are run. The web site also describes some of the problems with trying to use sudo directly for everything (such as pipelines).

If you compile Bash version 4.1 with the SYSLOG_HISTORY macro enabled (which can be done by editing the file config-top.h) then it will log all commands to syslog. RootShell.be has a short post about this which mentions the security issues, some commands take passwords as parameters and these passwords could be exposed to the network [5]. Of course the best option is to just avoid such commands. Thanks to Chris Samuel for pointing out the Bash logging feature.

Conclusion

If you use sudo for auditing root access then you lose some shell functionality. Sudo also only logs the commands that are executed – you don’t get logging of output. It seems that depending on the exact needs either a modified version of Sudoshell or the logging that can be compiled in to Bash would be the way to go depending on the exact requirements. The main benefit of using sudo for logging would be that some distributions of Linux are configured that way by default – but it seems unlikely that someone would go to the effort of running a separate logging server that the regular sysadmin team can’t touch and then configure their servers in a default manner.

Mailing List Meta-Discussions

It seems that most mailing lists occasionally have meta-discussions about what is on-topic, the few that don’t are the ones that have very strong moderation – authoritarian moderators who jump on the first infraction and clearly specify the rules.

I don’t recall the list of acceptable topics for any mailing list including “also discussions about what is on-topic“. As this is the Internet I’m sure that someone will immediately point out an example of such a list, but apart from the counter-example that someone will provide it seems obvious that for the majority of mailing lists a meta-discussion is not strictly on topic.

Regardless of a meta-discussion not being on-topic I don’t think there’s anything wrong with such a discussion on occasion. But if a meta-discussion is to be based on the volume of off-topic messages it would be nice if the people who advocate such a position could try and encourage the discussion in a way that reduced the number of messages. Replying to lots of messages is not a good strategy if your position is that there are too many messages.

If a meta-discussion is going to be about moving off-topic discussions to other forums that are more appropriate then it would be nice to have the meta-discussion move to another forum if possible. My previous post which advocates creating a separate mailing list for chatty messages was an attempt to move a discussion to a different forum [1]. Anyone who believes that such discussions don’t belong on a list such as debian-private is free to commit their thoughts to some place that they consider more appropriate and provide the URL to any interested parties. I think that it’s worth noting that the only comment on my previous post is one that describes how to filter mail to split the traffic from the debian-private list into different mailboxes. I had hoped that other people would write blog posts advocating their positions which would allow us to consider the merits of various ideas without the he-said-she-said element of mailing list discussions.

Most mailing lists have a policy against profanity and some go further and ban personal abuse. Therefore it seems hypocritical to advocate a strict interpretation of the rules in regard to what is on-topic while also breaking the rules regarding profanity or personal abuse. I don’t think it’s asking a lot to suggest that the small minority of messages that someone writes on the topic of a list meta-discussion should obey the set of rules that they advocate – I’m not suggesting that someone should obey all the rules all the time, just when they are trying to enforce them. Also you can argue that a list policy against profanity doesn’t preclude sending profane messages off-list, but if the off-list messages are for the purpose of promoting the list rules it still seems hypocritical to use profanity.

It is a fair point that off-topic discussions and jokes can distract people from important issues and derail important discussions. It would be good if people who take such positions would implement them in terms of meta-discussions. If the purpose of a meta-discussion is to avoid distraction from important issues then it seems like a really good idea to try and avoid distraction in the meta-discussion thread.

I wonder whether a meta-discussion can provide anything other than a source of lulz for all the people who don’t care about the issue in question. The meta-discussions in the Debian project seem to always result in nothing changing, not even when the majority of people who comment agree that the current situation is not ideal. When an almost identical meta-discussion happens regularly it seems particularly pointless to start such a discussion for the purpose of reducing off-topic content. Revisiting an old discussion can do some good when circumstances change or when someone has some new insight. I know that it’s difficult to avoid being sucked into such discussions, when I was diagnosed with AS [2] I decided to try and minimise my involvement in such discussions – but I haven’t been as successful at doing so as I had hoped.

Does Every Serious Mailing List need a Non-Serious Counterpart?

One practice that seems relatively common is for an organisation to have two main mailing lists, one for serious discussions that are expected to be relatively topical and another for anything that’s not overly offensive. Humans are inherently incapable of avoiding social chatter when doing serious work. The people who don’t want certain social interactions with their colleagues can find it annoying to have both social and serious discussions on the same list. While the people who want social discussions get annoyed when people ask them to keep discussions on topic.

Organisations that I have been involved with have had mailing lists such as foo-chat and foo-talk for social discussions that involve the same people as the main list named “foo“, as well as having list names such as “memo-list” for random discussions that are separate from a large collection of lists which demand on-topic messages.

The Debian project has some similar issues with the debian-private mailing list which is virtually required reading for Debian Developers. One complication that Debian has is that the debian-private list has certain privacy requirements (messages will be declassified after 3 years unless the author requests that they remain secret forever) which make it more difficult to migrate a discussion. You can’t just migrate a discussion from a private list to a public list without leaking some information. So it seems to me that the best solution might be to have a list named debian-private-chat which has the same secrecy requirements but which is not required reading. As debates about what discussions are suitable for debian-private have been going on for more than 3 years I don’t think there’s any reason not to publish the fact that such discussions take place.

Also it seems that every organisation of moderate scale that has a similar use of email and for which members socialise with each other could benefit from a similar mailing list structure. Note that I use a broad definition of the word “socialise” – there’s a lot of people who will never meet in person and a lot of the discussions are vaguely related to the main topic.

I wonder whether it might be considered to be a best practice to automatically create a chat list at the same time as creating a serious discussion list.

Is the PC Dying?

I just read an interesting article about the dispute between Microsoft and Apple about types of PC [1]. Steve Jobs predicted a switch from desktop PCs to portable devices, while Steve Ballmer of Microsoft claimed that the iPad is just a new PC.

Defining a PC

I think that the defining characteristic of the IBM Compatible PC was it’s open architecture. Right from the start the PC could have it’s hardware expanded by adding new circuit boards into slots on the motherboard (similar to other PC systems of that era such as the Apple 2 and the S-100 bus). The deal with IBM included Intel sharing all it’s CPU designs with other manufacturers such as NEC and AMD from the 8086 until the mid-90’s. AMD specialised in chips that were close copies of Intel chips at low prices and higher clock rates while NEC added new instructions. Compaq started the PC clone market as well as the laptop market, and system software for the IBM compatible PCs was primarily available from IBM and Microsoft in the early days, along with less popular variants such as CP/M86, Novell Netware and others. In the late 80’s there was OS/2 as an alternate OS and Windows as one of several optional GUI environments to run on top of MS-DOS or PC-DOS. In the mid 90’s PCs were used for running protected mode OSs such as Linux and Windows/NT.

Now if we look at a system such as a Netbook then it clearly misses some of the defining characteristics of the desktop PC. I can’t upgrade a Netbook in any meaningful way – changing a storage device or adding more RAM does not compare to adding an ISA/MCA/EISA/VL-Bus/PCI/PCIe expansion card. With my EeePC 701 I don’t even have an option of replacing the storage as it is soldered to the motherboard! A laptop allows me to add a PCMCIA or PC-Card device to expand it, but with a maximum of two cards and a high price this isn’t a great option.

What is Best for Home Users?

For a while now my parents have been using 3G net access for their home Internet use [2]. So it seems that a laptop provides greater benefits for their use now than it previously did when they used Cable and ADSL net access. My parents have been considering getting a new monitor (1920*1080 resolution monitors are getting insanely cheap nowadays) and driving such a monitor effectively might require a more capable PC. I recently bought myself a nice refurbished Thinkpad for $796 [3], it seems likely that I could find a refurbished Thinkpad at auction which is a little older and slower for a lower price, even buying an old T41p would be a reasonable option. This would give my parents not only the option of using the Internet when on holidays, but also in a different part of their house when they are at home.

The Apple iPad would probably be quite a reasonable Internet platform for my parents if it wasn’t for the fact that it uses DRM. While it’s not a great platform for writing, my parents probably don’t do enough that it would be a huge problem for them. So I might look for a less restrictive tablet platform for my parents. At the moment the best resolution for a tablet seems to be 1024*768, but I expect that some tablets (maybe with a hybrid tablet/laptop design like the Always Innovating Smartbook [4]) with a higher resolution will be released soon. I hope that the iPad and other closed devices don’t get any serious market share, but it seems likely that OSs such as Android which are only slightly more open will have a significant market share.

Ultra-Mobile Design vs PCs Design

One significant problem with ultra-mobile devices is that they make significant engineering trade-offs to get the small size. For a desktop system there are lots of ways of doing things inefficiently, running the AMD64 or i386 architecture which is wasteful of energy and having lots of unused space inside the box in case you decide to upgrade it. But for a laptop there are few opportunities for being inefficient, and for a tablet or smart phone everything has to be optimised. When the optimisation of a device starts by choosing a CPU that’s unlike most other systems (note that there is a significant range of ARM CPUs that are not fully compatible with each other) it makes it very difficult to produce free software to run it. I can salvage a desktop PC from a rubbish bin and run Linux on it (and I’ve done that many times), but I wouldn’t even bother trying to run Linux on an old mobile phone.

It seems that in the near future my parents (and many other people with similar needs) will be best suited by having a limited device such as a tablet that stores all data on the Internet and not having anything that greatly resembles a PC. In many ways it would be easier for me to support my parents by storing their data in the cloud and then automatically backing it up to removable SATA disks than with my current situation of supporting a fully capable PC and backing it up to a USB device whenever I visit them.

I’m also considering what to do for some relatives who are about to go on a holiday in Europe, they want to be able to send email etc. It might not be possible just yet, but it seems like an ideal way of doing this would be to provide them with something like an iPad that they can use with a local 3G SIM for the country that they stay in and they could then upload all their best photos to some server that I can backup and send email to everyone they know. An iPad isn’t good for this now as you don’t want to go on holidays in another country while carrying something that is really desirable to thieves.

Ultra Mobile Devices are Killing PCs

It seems to me that Google Android and the Apple iPad/iPhone OS are taking over significant parts of the PC market. The people who are doing traditional PC things are increasingly using Laptops and Netbooks, and the number of people who get the freedom that a PC user did in the 80’s and 90’s is decreasing rapidly.

I predict that by 2012 the majority of Linux systems will be running Google Android on hardware that doesn’t easily allow upgrading to more open software. At the moment probably the majority of Linux systems are wireless routers and other embedded devices that people don’t generally think about. But when iPad type devices running a locked-down Linux installation start replacing Ubuntu and Fedora desktop systems people will take notice.

I don’t think that the death of the PC platform as we know it will kill Linux, but it certainly won’t do us any good. If there were smarter people at Microsoft then they would be trying to work with the Linux community on developing innovative new ways of using desktop PCs. Of all the attempts that Microsoft has made to leave the PC platform the only success has been the X-Box which is apparently doing well.

Tablet devices such as the iPad could work really well in a corporate environment (where MS makes most of it’s money). On many occasions I’ve been in a meeting and we had to adjourn due to someone needing to go to their desk to look something up. If everyone had an iPad type device at their desk that used a wired network when it was available and encrypted wireless otherwise then for a meeting everyone could take their tablet without it’s keyboard and be able to consult all the usual sources of data without any interruption.

Could a high-resolution version of the iPad kill MS-Windows in the corporate environment?

Bugs in Google Chrome

I’m currently running google-chrome-beta version 5.0.375.55-r47796 on Debian/Unstable. It’s the fastest web browser I’ve used in recent times – it’s the first time that I’ve run a browser that feels faster than my recollection of running IBM WebExplorer for OS/2 on a 486-66 system! It has a good feature set, and it’s the only browser I’ve used that in a typical configuration will make proper use of the screen space by not having a permanent status bar at the bottom of the sceen and by having tabs in the title-bar. But it’s not perfect, here is a list of some bugs:

Right of Chrome Titlebar when not maximised

Above are three partial screen captures of Chrome, the first is when maximised and the second is when the window isn’t maximised. Notice the extra vertical space above the tab in the title bar in the second picture. The third picture shows the right side of the titlebar and you can see a space below the three buttons where you can drag the window around – no matter how many tabs you open that space below the three buttons is reserved. If the Chrome developers had removed the extra vertical space in the titlebar and reserved slightly more horizontal space then you would be able to drag the window around. While an anonymous commentator made a good point that the extra vertical space can be used to drag the window around when the maximum number of tabs are open, it seems that there are other ways of achieving that goal without wasting ~18 vertical pixels. Doing so would be a lot less ugly than what they did with finding text in the page.

When I visit a web site that uses cookies from an Incognito Window (which means that cookies etc aren’t stored) there is no option to say “allow all cookies”. This is really annoying when you get to a web site such as the IBM one which stores 5 cookies when you first load the page and then at least one new cookie write for every page you visit. Given that cookie data will be discarded as soon as the window is closed it seems like a good idea to have an option to allow all cookies for Incognito Windows even if all cookies aren’t allowed for regular windows. Blocking all cookies would be OK too, anything but having to click on Block or Allow multiple times for each page load.

The J and K keys don’t work in a view of Venus version 0~bzr95-2+lenny1 (the latest version in Debian/Lenny).

I once had a situation where I entered a ‘.’ at the end of a domain name (which is quite legal – there is always an implied dot) and Chrome then wouldn’t take note of my request to accept all cookies from the domain. I haven’t been able to reproduce that bug, but I have noticed that it stores the settings for whether cookies should be stored separately for domains that end in ‘.’, so “www.cnn.com.” is different from “www.cnn.com” . Iceweasel seems to just quietly strip the trailing dot. Of course this is better than Konqueror which won’t even load a URL with a dot at the end.

Chrome can be relied on to restore all windows rapidly after a crash, unlike Iceweasel which restores them at it’s normal load speed (slow) and Konqueror which doesn’t tend to restore windows. This is good as it does seem to crash regularly. In a response to my post about Chrome and SE Linux [1] Ben Hutchings pointed out that the --no-sandbox option to chrome disables the creation of a PID namespace and therefore makes debugging a lot easier, if I get a lot of spare time I’ll try and track down some of the Chrome SEGVs.

The JavaScript compiler is either buggy or it’s not buggy in situations where people expect IE bugs. When using the Dell Australia web site I can’t always order all options. When trying to order a Dell R300 1RU server with hot-plug disks in a hardware RAID array it seems impossible to get all the necessary jumpers – which is a precondition to completing the order – fortunately I only wanted to blog about how cheap Dell servers are so I don’t actually need to complete an order. Dell’s web site is also difficult in Iceweasel on occasion, so it’s obviously more demanding than most sites. It might be a good test site for people who work on browsers as it’s both demanding and important.

When I select a URL to be opened in a new window (or when JavaScript does this) then the new tab is opened with about:blank listed as the URL. If the URL is for a PDF file (or something else that is to be downloaded) then the URL entry field is never updated to give the real URL. I believe that this is wrong, either the new tab shouldn’t be opened or it should have the correct URL on display – there is no benefit with a tab open to show nothing but about:blank in the URL entry field. Also if a URL takes some time to load then it may keep about:blank in the URL entry field for some time. This means that if you use the middle mouse button to rapidly open a few new tabs you won’t be able to see what is to be loaded in each one. Sometimes I have several tabs loading and I’m happy to close some unimportant ones if they are slow but some are worth waiting for.

Overall that’s not too bad. I can use Dell’s site in Iceweasel, so the only critical bug is the cookies issue in Incognito Windows which makes the Incognito feature almost unusable for some sites.

[1] http://etbe.coker.com.au/2010/05/19/google-chrome-and-se-linux/

Securely Killing Processes

Joey Hess wrote on Debian-devel about the problem of init scripts not doing adequate checks before using the data from a PID file under /var/run to determine which process to kill [1]. Unfortunately that still doesn’t quite solve the problem, there is still the issue of a race condition causing a process to die while you are doing the checks and then be replaced by another process.

Below I have included the source code to a little program that will repeatedly fork() until it finds a particular PID and then have it’s child call sleep(). So you can run a command such as “kill -9 1234 ; ./a.out 1234” and then have this program take over the PID 1234.

From testing with this it seems that when you have a shell with it’s current working directory as /proc/1234 then once process 1234 is killed the current directory is empty, “ls -l” returns 0 entries. This isn’t surprising, it’s the standard Unix behavior when the working directory is removed.

So if a program (or even a shell script) changes directory to /proc/1234 it can then verify all attributes of the process (it’s CWD, it’s root directory, the executable used to run it, it’s UID, GID, supplemental groups, it’s SE Linux context, and lots of other things all atomically. The only possibility for confusion is that a process might execute a SETUID or SETGID program or a program that has a label which triggers a SE Linux domain transition. It might also change some attributes without executing a new process, for example by using the setuid(), setgid(), setgroups(), or other similar system calls. For the purposes of killing a process I don’t think that the possibility of it changing it’s own attributes or executing a new program are serious problems, if you want to kill a process then you probably want to kill it after it has called setuid() etc.

It seems to me that it would be useful to have a file named /proc/PID/signal (or something similar) to which you could write a number and then have the kernel send the signal in question to that process. So the commands “kill -9 1234” and “echo 9 > /proc/1234/signal” would give the same result. But you could run the command “cd /proc/1234” and then some time later you could run “echo 9 > signal” and know that you would kill the original process 1234 if it was still running and not some other process that replaced it.

What do you think? Is this worthy of adding a new feature to the proc filesystem?

The Source

Run the following program with a single parameter which is the PID that you want it to take. It will keep looping through the PID space until it gets the one you specify, if the one you specify isn’t available (EG you give it “1” as a parameter) then it will run forever. It will take some time to get a result on a slower system. On my P3-900MHz test system it took up to 72 seconds to get a result.

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/wait.h>

int main(int argc, char **argv)
{
if(argc != 2)
{
printf("Specify the desired PID on the command-line\n");
return 1;
}
pid_t wanted = (pid_t)atoi(argv[1]);
int rc;
int status;
while((rc = fork()) != wanted && rc != 0)
{
if(rc == -1)
{
printf("fork error\n");
return 1;
}
if(wait(&status) == -1)
printf("wait error\n");
}
if(rc == 0)
{
if(getpid() == wanted)
{
printf("Got pid %d, sleeping\n", wanted);
sleep(200);
}
return 0;
}
wait(&status);
return 0;
}

[1] http://lists.debian.org/debian-devel/2010/05/msg00067.html

Can SE Linux Implement Traditional Unix Users and Groups?

I was asked by email whether SE Linux could implement traditional Unix users and groups.

The Strictly Literal Answer to that Question

The core of the SE Linux access control is the domain-type model where every process has a domain and every object that a process can access (including other processes) has a type. Domains are not strongly differentiated from types.

It would be possible to create a SE Linux policy that created a domain for every combination of UID and GID that is valid for a user shell given that such combinations are chosen by the sysadmin who could limit them to some degree. There are about 2^32 possible UIDs and about 2^32 possible GIDs, as every domain is listed in kernel memory we obviously can’t have 2^64 domains, but we could have enough to map a typical system that’s in use. Of course the possible combinations of supplemental groups probably makes this impossible for even relatively small systems, but we can use a simpler model that doesn’t emulate supplemental groups.

For files there are more possible combinations because anyone who is a member of a group can create a SETGID directory and let other users create files in it. But in a typical system the number of groups is not much greater than the number of users – the maximum number of groups is typically the number of users plus about 60. So if we had 100 users then the number of combinations of UID and GID would be something like 100*(100+60)=16,000 – it should be possible to have that many domains in a SE Linux policy (but not desirable).

Then all that would be needed is rules specifying that each domain (which is based on a combination of UID and GID) can have certain types of access to certain other types based on them having either the same UID or the same GID.

Such a policy would be large, it would waste a lot of kernel memory, it would need to be regenerated whenever a user is added, and it’s generally something you don’t want to use. No-one has considered implementing such a policy, I merely describe it to illustrate why certain configuration options are not desirable. The rest of this post is about realistic things that you can do with SE Linux policy and how it will be implemented in Debian/Squeeze.

My previous post titled “Is SE Linux Unixish?” addresses this issue at a more conceptual level and also considers MAC vs DAC [1].

The History of mapping Unix Accounts to SE Linux Access Control

In the early releases of SE Linux (long before it was included in Fedora) every user who could login to a system needed to have their user-name compiled into the policy. The policy specified which roles the user could access, the roles specified which domains could be accessed, and therefore what the user could do. The identity of files on disk was used for two purposes, one was logging (you could see who created a file) and the other was a permission check for the SE Linux patched version of Vixie cron which would not execute any command on behalf of a user unless the identity on the crontab file in the cron spool matched the identity used to run it – this is an analogy of the checks that Vixie cron makes on the Unix UID of the crontab file (some other cron daemons do fewer checks).

Having to recompile policy source every time you added a user was annoying. So a later development was to allow arbitrary mappings between Unix account names and SE Linux Identities (which included a default identity) and another later development was to have a utility program semanage to map particular Unix account and group names to SE Linux identities. This was all done years ago. Fedora Core 5 which was released in 2006 had the modular policy which included these features (apart from mapping Unix groups to SE Linux identities which was more recent).

Fedora Core 5 also introduced MCS which was comprised of a set of categories that a security context may have. The sysadmin would configure the set of categories that each account would have.

A recent development has been a concept named UBAC (User Based Access Control) which basically means that a process running directly on behalf of a regular user (IE with a SE Linux identity that’s not system_u) can only access files that have an identity of system_u or which have the same identity as the process. This means that you can only access your own files or system files – not files of other users which may have inappropriate Unix permissions. So for example if a user with a SE Linux identity of “john” gives their home directory the Unix permission mode of 0777 then a user with a SE Linux identity of “jane” can’t access their files. Of course this means that if you have a group of people working together on a project then they probably need to all have the same Identity and in practice you would probably end up with everyone having the same identity. I’ve given up on the idea of using UBAC in Debian.

The Current Plan for Users and SE Linux Access Control in Debian

My plan is to have things work in Squeeze in much the same way as in Lenny.

You have a SE Linux identity assigned to a login session and everything related to it (including cron jobs) based on the Unix account name or possibly the Unix group name (if there are login entries for both the user-name and the group-name then the user-name entry has precedence). The mapping between Unix accounts and SE Linux identities is configured by the sysadmin and SE Linux identities don’t matter much for the Targeted configuration (which is what most people use).

The identity determines which roles may be used and also has a limit on the MCS categories. The MCS categories are also specified in the login configuration which has to be a sub-set of the categories used by the identity record.

So for example the following is the output of a couple of commands run on a Debian/Unstable system. They show that the “test” Unix account is assigned a SE Linux identity of “staff_u” and an MCS range of “s0-s0:c1” (this means it creates files by default at level “s0” and can also write to other files at that level, but can also have read/write access to files at the level “s0:c1”). The “staff_u” identity (as shown in the output of “semanage user -l” can be used with all categories in the set “s0:c0.c1023” where the dot means the set of categories from c0 to c1023 inclusive) but in the case of the “test” user only one category will be used. The “test” group however (as expressed with “%test”) is given the identity “user_u” and is not permitted to use any categories.

# semanage login -l
Login Name    SELinux User    MLS/MCS Range            
%test         user_u          s0                       
__default__   unconfined_u    s0-s0:c0.c1023           
root          unconfined_u    s0-s0:c0.c1023           
system_u      system_u        s0-s0:c0.c1023           
test          staff_u         s0-s0:c1               

# semanage user -l
             Labeling   MLS/       MLS/                          
SELinux User Prefix     MCS Level  MCS Range         SELinux Roles
root         sysadm     s0         s0-s0:c0.c1023    staff_r sysadm_r system_r
staff_u      staff      s0         s0-s0:c0.c1023    staff_r sysadm_r
sysadm_u     sysadm     s0         s0-s0:c0.c1023    sysadm_r
system_u     user       s0         s0-s0:c0.c1023    system_r
unconfined_u unconfined s0         s0-s0:c0.c1023    system_r unconfined_r
user_u       user       s0         s0                user_r

I hope to get the policy written to support multiple user roles in time for the release of Squeeze. If I don’t make it then I will put such a policy on my own web site and try to get it included in an update. The policy currently basically works for a Targeted configuration where the users are not confined (apart from MCS).

How MMCS Basically Works

The vast majority of SE Linux users run with the MCS policy rather than the MLS policy. For Debian I have written a modified version of MCS that I call MMCS. MMCS is mandatory (you can’t relabel files to escape it) and it prevents write-down.

If a process has the range s0-s0:c1,c3 then it has full access to files labelled as s0, s0:c1, s0:c3, and s0:c1,c3 – and any files it creates will be labeled as s0.

If a process has the range s0:c1-s0:c1,c3 then it has read-only access to files labelled as s0 and s0:c3 and read-write access to files labelled as s0:c1 and s0:c1,c3. This means that any secret data it accesses that was labelled with category c1 can’t be leaked down to a file that is not labelled with that category.

Now MCS currently has no network access controls, so there’s nothing stopping a user from using scp or other network utilities to transfer files. But that’s the way with most usable systems. I don’t think that this is necessarily a problem, the almost total lack of network access controls in a traditional Unix model doesn’t seem to concern most people.

Now to REALLY Answer that Question

SE Linux is a Mandatory Access Control (MAC) system, this makes it inherently different to a Discretionary Access Control (DAC) system such as traditional Unix access controls.

Unix permissions are based on each file having a UID, a GID, and a set of permissions and each process having a UID, a GID, and a set of supplementary GIDs. If a user runs a setuid or setgid program then the process will have extra privileges. It also has a lot of stuff that most people aren’t aware of such as real vs effective UIDs, the tag bit, setgid directories, and lots more – including some quite arbitrary things like making ports <1024 special.

SE Linux is based on every object (process, file, socket, etc) having a single security label which includes an identity, a role, a type, and a sensitivity label (MCS categories or an MLS range). There is no support for an object to have more than one label. The SE Linux equivalent to setuid/setgid files is a label for a file which triggers a domain transition when it’s executed. This differs from setuid files in that the domain transition is complete (the old privileges can’t be restored) and the transition is generally not to a strict super-set of the access (usually a different sub-set of possible access and sometimes to lesser access).

These differences are quite fundamental. So really SE Linux can’t implement traditional Unix access control. What SE Linux is designed to do is to provide a second layer of defense and to also provide access controls that have different aims than that of Unix permissions – such as being mandatory and implementing features such as MLS.

[1] http://etbe.coker.com.au/2008/08/25/is-se-linux-unixish/

etbe – Russell Coker

Archives

Categories

Should Passwords Expire?

Can a Password be Semi-Public?

Why are terms such as Three Months used for Maximum Password Ages?

Can there be a Delay between a Password being Compromised and being Used by an Attacker?

How are Passwords typically Compromised?

Can a Password Last Forever?

Should a Password be the only Authentication Method?

Conclusion

Related Posts

Defense in Depth and Sudo

Can using sudo provide Defense in Depth benefits?

Conclusion

Links June 2010

Logging Shell Commands

Ways of Logging Shell Commands

Conclusion

Mailing List Meta-Discussions

Does Every Serious Mailing List need a Non-Serious Counterpart?

Is the PC Dying?

Defining a PC

What is Best for Home Users?

Ultra-Mobile Design vs PCs Design

Ultra Mobile Devices are Killing PCs

Bugs in Google Chrome

Securely Killing Processes

The Source

Can SE Linux Implement Traditional Unix Users and Groups?

The Strictly Literal Answer to that Question

The History of mapping Unix Accounts to SE Linux Access Control

The Current Plan for Users and SE Linux Access Control in Debian

How MMCS Basically Works

Now to REALLY Answer that Question

Archives

Email and RSS

Archives

Categories

Tags

Can a Password be Semi-Public?

Why are terms such as Three Months used for Maximum Password Ages?

Can there be a Delay between a Password being Compromised and being Used by an Attacker?

How are Passwords typically Compromised?

Can a Password Last Forever?

Should a Password be the only Authentication Method?

Conclusion

Related Posts

Can using sudo provide Defense in Depth benefits?

Conclusion

Ways of Logging Shell Commands

Conclusion

Defining a PC

What is Best for Home Users?

Ultra-Mobile Design vs PCs Design

Ultra Mobile Devices are Killing PCs

The Source

The Strictly Literal Answer to that Question

The History of mapping Unix Accounts to SE Linux Access Control

The Current Plan for Users and SE Linux Access Control in Debian

How MMCS Basically Works

Now to REALLY Answer that Question

Archives

Email and RSS