LWN: Comments on "A kernel.org status update"

Mobile Phones

robbe — Thu, 06 Oct 2011 20:26:12 +0000

Assuming your phone is safe gets more dumb whenever phones get smarter. There are now banking trojans which include smartphone attacks in their repertoire.

Oh well, and there's the insecurity of the GSM network to consider. That will probably only be a factor in targeted attacks. The kernel.org story looks more like a drive-by break-in striking a jackpot.

But if you want it, Duo Security provides such a service. They have a pam module, IIRC.

A kernel.org status update

joern — Sat, 01 Oct 2011 12:21:39 +0000

> A good rule to secure the admin's machines (apart from the secure configuration of the machine itself) is to forbid any direct interaction with dangerous sources : email, web. While this is cumbersome, this is way safer.

Or you can grant yourself a few extra accounts and ssh into your web user, etc. Depending on paranoia level and impact in case of a compromise, you can ssh into different machines as well, be they virtual or not.

I started doing this because mixing random web browsing with online banking or sites that require typing in your credit card number in the same long-running browser with a large amount of functionality (read: attack surface) didn't seem a very smart idea. Now at least the attacker will have to crawl back through an ssh connection he cannot initiate, which gives me an extra layer of security.

A shell mail agent like mutt or pine also helps make that particular hole a lot tighter.

And as a general rule, if a small amount of extra security requires a large amount of inconvenience, that extra security will be circumvented in a way that reduces overall security. Just like 3-month password requirements lead to notes under keyboards and identical passwords on dozens of machines, etc.

Mobile Phones

mpr22 — Fri, 30 Sep 2011 11:54:08 +0000

Saying "an SMS" to mean an SMS text message is acceptable usage in most English-language contexts. It's not the most æsthetically satisfactory usage, but I have no problem with it despite being the kind of person who treats excessive pedantry as something close to a hobby.

Defense in depth

cdmiller — Thu, 29 Sep 2011 21:45:57 +0000

Perhaps openbsd...

Mobile Phones

smurf — Thu, 29 Sep 2011 13:20:37 +0000

You typically don't reply to that text message. You enter the code which the bank transmitted into the SSL web page you're paying through.

"You have internet but your GSM phone doesn't work" doesn't happen all that often. If it does, you need alternate ways to pay, but that's nothing new.

NB: It's a text message, or "text" for short. Or a SM if you prefer, though that tends to have unwanted connotations. ;-) SMS is "Short Message Service". One does not send services.

Defence in depth

trasz — Thu, 29 Sep 2011 12:49:57 +0000

Of course it is. STOP (XTS-400), for example.

Mobile Phones

etienne — Thu, 29 Sep 2011 12:29:54 +0000

> I quite like the way banks now send SMSes asking you to confirm transactions. Assuming your phone is secure (or not compromised at the same time as your PC), then that is pretty safe.

Hem... if the bank has a delivery confirmation of the SMS and you can reply to that SMS with another SMS it should be fine.
Ever heard of SMS arriving hours late?
Ever been in holidays in a country with no SMS coverage (your GSM phone is not authorised in that county...), trying to check-out your hotel?
If you do not reply to that SMS (or do not reply to any SMS during your week holidays) what does the bank do?

A kernel.org status update

tothaa — Wed, 28 Sep 2011 14:07:02 +0000

We like you, kernel.org! You have done so many good in the past, and we are waiting your next step to come.

Mobile Phones

gmatht — Wed, 28 Sep 2011 13:53:56 +0000

I quite like the way banks now send SMSes asking you to confirm transactions. Assuming your phone is secure (or not compromised at the same time as your PC), then that is pretty safe.

It isn't as easily applied to development, but I can imagine that an android app to confirm commits could be handy for developers who are working on sensitive projects or mainly submit small patches. It would probably catch more mistakes than hacking attempts though.

A kernel.org status update

Lennie — Wed, 28 Sep 2011 11:40:45 +0000

My comment wasn't very serious, just pointing out it is a possibility.

Although probably slim as you mentioned.

A kernel.org status update

Lennie — Wed, 28 Sep 2011 11:36:49 +0000

Have to admit my comment wasn't very serious, just saying it is a possibility. Although probably slim.

Pity there's no secure version of the git protocol

njs — Wed, 28 Sep 2011 07:28:47 +0000

Sadly, only root can install an ssh subsystem, so tunneling a protocol over a plain ssh session is easier, and accomplishes the same thing.

Defence in depth

mpr22 — Tue, 27 Sep 2011 23:06:28 +0000

Didn't Sun boxes have IOMMUs in the 90s? (OK, not exactly commodity hardware...)

A kernel.org status update

rickmoen — Tue, 27 Sep 2011 22:38:33 +0000

As a follow-up, it also appears that a good assessment of Jon Larimer's presentation was posted by Kees Cook.

Rick Moen
rick@linuxmafia.com

A kernel.org status update

rickmoen — Tue, 27 Sep 2011 22:19:03 +0000

Although I personally eschew GNOME, I notice that your data cited for 'Linux is sometimes also vulnerable to autorun attacks' is not only GNOME-specific (not 'Linux'), but, even at that, paper-thin at best.

1. Freedesktop.org/GNOME specs say that autorun at mount time is allowed but must always ask for user confirmation. My friends who run GNOME say that this precaution or more-draconian ones are implemented in distro packages of Nautilus, gio/gvfs, or whatever it is these days.

Above is the only part of Larimer's presentation that is in any way comparable to Stuxnet's autorun on mount of USB sticks.

2. Larimer makes a handwave about exploiting the GNOME (Nautilus) thumbnailer code and related thumbnailers, or vfs mass-storage hardware handlers (usbcore, udev, d-bus, udisks, etc.), or filesystem handlers through feeding them aberrant public data, which is of course always a concern (in the sense that any code handling public data is security-sensitive), but experience and forensics suggest that, although it's far too often possible to make such code segfault, it's orders of magnitude more difficult to turn such crashes into execution of arbitrary code.

Jake Edge reviewed Larimer's talk when he gave it, and offered further details about why Larimer's examples were more handwaving than practical, though, as he says, 'That should give anyone pause about automatically mounting those kinds of devices.'

Rick Moen
rick@linuxmafia.com

Defence in depth

cmccabe — Tue, 27 Sep 2011 20:59:48 +0000

Hmm, I didn't realize this feature was still so buggy. Still, in a few years, it will probably be considered as standard as the VT-x extensions.

IOMMUs are an interesting feature. I think if they had existed back in the 80s or 90s, operating systems might have evolved quite differently. Putting device drivers in userspace doesn't seem quite so absurd if they can access I/O ports safely. Of course, there are a lot of other things that would need to happen to make that a realistic choice, but it at least opens the door.

A kernel.org status update

nix — Tue, 27 Sep 2011 16:33:31 +0000

Extending the same metaphor, DigiNotar had a fortress in a distant barren land, with foot-thick stone walls... and a four-lane highway extending up to the entrance, and a one-cylinder lock on a door made of cardboard.

Defence in depth

nix — Tue, 27 Sep 2011 16:18:33 +0000

Probably the most interesting thing they've done so far is sandbox networking code using IOMMU/VT-d.

That assumes you have a machine on which this works, and is secure. Even the first is hard (my machines are top-end systems less than two years old and VT-d works on neither of them: on one it just fails to do anything useful and on the other it locks up the system hard on boot unless VT-d is turned off): the second is probably impossible given that huge holes requiring firmware-level changes were still being found in VT-d as recently as a few months ago. Are there any left? Do you feel lucky?

Defense in depth

nix — Tue, 27 Sep 2011 16:14:48 +0000

A real vote of no confidence would be if they chose to run kernel.org on Windows 7.

Pity there's no secure version of the git protocol

nix — Tue, 27 Sep 2011 16:09:46 +0000

An SSH subsystem is more like inetd: a way to write something that can take advantage of ssh's authentication and encryption while needing to do no more yourself than talk along stdin/stdout (talking to an ssh child on the client end, and to an sshd parent on the server end).

I'm amazed it isn't more widely used (perhaps the near-total absence of documentation explains it, although that is explained by the fact that there's almost nothing *to* document.)

A kernel.org status update

nix — Tue, 27 Sep 2011 15:49:53 +0000

Restricting access to sneakers-in-front-of-the-console doesn't improve security, though: it just makes it harder for legitimate users and changes the nature of the attack from 'compromise the network' to 'social-engineer yourself in front of the console'.

A kernel.org status update

nix — Tue, 27 Sep 2011 15:47:54 +0000

True enough. I misheard, then.

Hardware cryptographic dongles

ekj — Tue, 27 Sep 2011 11:07:38 +0000

I don't think it'd help significantly.

True, with a reasonably secure dongle, it's not possible for a software-only attack to steal the private key. But it's still possible for malicious software running on some developers machine, to do everything that developer can do.

Thus, if that developer can somehow push changes to kernel.org - then malicious software running on the developers machine can *also* do this, dongle or not.

A kernel.org status update

ebirdie — Tue, 27 Sep 2011 10:00:17 +0000

What, if it wasn't bad luck, but HPA was on the attack surface? He is a known high profile admin and developer.

I speculated about this scenario in couple comments here and here at lwn.net recently. I will not repeat them.

How conveniently for this comment, while I begun to dig links to the above comments from lwn.net, I was about to point "My Account" on left LWN.net bar and my attention was grasped by "Unread comments" link below the "My Account". What the heck is that, I thought. What a great feature, I have been missing, and as a regular daily lwn.net reader I remember there have been three items below "Logged in as" for ages.

What can be said? It is frightening how familiar things can hide features, you wasn't expecting them to have - say bugs or malicious payload for example.

If it turns out that HPA was on the attack surface, does this event deem us, admins, out of shell access and get sneakers on to front of the console for proper security?

A kernel.org status update

dsommers — Tue, 27 Sep 2011 07:29:48 +0000

Even the strongest, most secure piece of software might have vulnerabilities. There is no such thing as a completely secure software, nor hardware.

Building a secure system is like building a secure house. You can remove all doors and windows, but you can't get in and out from it. But you might have ventilation holes to be able breathe inside, and that can be yet another vulnerability (what if someone brings a water hose...?) You can build it on the top of a mountain - even without ventilation, without roads, or wires to this house. But it'll be pretty useless, as you can't do anything else than to observe how it looks from the outside (inside you wouldn't really survive). And still somebody can decide to send a rocket through your walls.

So as long as you want to have a computer on the Internet, you need to connect it to a network (a road to the house). And you need to enable some services (doors and windows) to be able to do something useful with it. Then security depends on what kind of services you open up and what kind of security layers ("guards" protecting the "house") you implement - which can be firewalling with or without deep packet inspection, SELinux, AppArmor, tcpwrapper, authentication mechanisms, etc, etc.

The only thing in which can make things more secure is layers of security mechanisms. If something nasty passes one layer it will hopefully be caught in the next layer. But in the end, it's really difficult to only catch the nasty stuff and only let through the good stuff.

Hardware cryptographic dongles

BrucePerens — Tue, 27 Sep 2011 04:26:43 +0000

Would hardware cryptographic dongles help? We can at least use them to protect private keys, and to get the developers to stop using just a password to authenticate to their own systems. But we can't prevent misuse of the dongle if it's plugged into a system that has been penetrated.

Defence in depth

Cyberax — Tue, 27 Sep 2011 03:37:59 +0000

Well, it depends on a definition of 'secure'. At least, SeL4 is formally correct and verified which automatically kills a lot of possible attack vectors.

Capability-based security properties are easily proven, but not very interesting.

A kernel.org status update

rgmoore — Mon, 26 Sep 2011 22:32:50 +0000

It's not just the kernel, though; you can be compromised through userspace or social engineering. In this case, for example, there's no indication that the initial compromise had anything to do with the kernel being insecure. Running a system securely involves more than just software; it requires good procedures as well. Limiting the number of people who have shell access to key servers is one part of those good procedures.

Defence in depth

cmccabe — Mon, 26 Sep 2011 22:15:09 +0000

Well, there is Quebes, which is a little less pie-in-the-sky.

http://qubes-os.org/Home.html

disclaimer: I haven't actually gotten around to trying this "distro."

Probably the most interesting thing they've done so far is sandbox networking code using IOMMU/VT-d.

A kernel.org status update

Trou.fr — Mon, 26 Sep 2011 21:57:19 +0000

Sure, USB sticks are also an attack vector, but the risk of such targeted attacks is lower... but maybe not for someone trying to backdoor the kernel.

Defence in depth

dgm — Mon, 26 Sep 2011 21:27:02 +0000

> So a secure OS is still not possible. At least no one has done so yet.

I would be more correct to say that, even if someone did a completely "secure" OS, we cannot prove it as we don't know precisely what "secure" means. But this doesn't rule out the existence of a it, just that we cannot be sure.

SSH keys

njs — Mon, 26 Sep 2011 21:11:46 +0000

Cryptographers generally frown on re-using the same keying material in multiple protocols, since there can be nasty interactions. Even if two protocols are individually secure, it's possible that one protocol will reveal information about the key that lets you break the other protocol. (For instance, public-key based login protocols will often have the server issue a nonce, which the client will sign and send back, to prove that it has the private key. Consider what happens if your client is using your PGP key, and the server just so happens to choose a nonce which is also a valid email message...)

Sending an SSH key in a PGP-signed message avoids this problem, and still lets you use the web of trust.

Defence in depth

smurf — Mon, 26 Sep 2011 20:51:38 +0000

Also, from the same FAQ:

Microkernels typically do not provide device drivers, file systems or network stacks.

A secure kernel without storage or networking is somewhat under-featureful to run on machines like kernel.org, I'd say. Have fun formally specifying the operation of your typical high-end network adapter or SATA controller. You'll need it; see you in a few years. ;-)

There's also no formal proof for multi-core systems, arguably also a necessity these days.

Defence in depth

nevets — Mon, 26 Sep 2011 20:23:00 +0000

There ARE totally secure networked multi-user kernels. Here it is: http://ertos.nicta.com.au/research/l4.verified/

From their own FAQ.

Is seL4 proven secure?

No, it is not. The proof states and shows functional correctness, not security. Functional correctness implies the absence of many security common problems, provided the proof assumptions hold (see also the longer version), but it does not mean that the kernel or system as a whole is "secure". Such a statement would first require a precise mathematical definition of what secure means. We are working on proving precisely defined, high-level security properties of seL4 in the future. These proofs will provide stronger assurance than what is possible of current systems, but they will still be up to assumptions and classes of attack vectors.

[bold added by me]

So a secure OS is still not possible. At least no one has done so yet.

Defence in depth

Cyberax — Mon, 26 Sep 2011 19:53:27 +0000

There ARE totally secure networked multi-user kernels. Here it is: http://ertos.nicta.com.au/research/l4.verified/

Formally verified kernels which are immune to stack overflow and other low-level hacks are a-plenty. Even hardware IOMMU is common already.

So a secure OS is possible and probably would be implemented sooner or later.

Pity there's no secure version of the git protocol

jnareb — Mon, 26 Sep 2011 17:06:11 +0000

Git supported push via "dumb" HTTPS using WebDAV for a very long time, and from some time support push via "smart" HTTP protocol (with a CGI script, that runs git-receive-pack / git-upload-pack, e.g. git-http-backend).

As with push via SSH Git left security to SSH, with push via HTTPS Git leaves security to HTTPS / web server configuration.

Defence in depth

mpr22 — Mon, 26 Sep 2011 14:56:26 +0000

A well-secured system doesn't offer unnecessary facilities to its special-purpose users. Anyone who doesn't need shell access on kernel.org's servers shouldn't have shell access on kernel.org's servers.

Pity there's no secure version of the git protocol

pboddie — Mon, 26 Sep 2011 14:55:44 +0000

Don't any of the Git solutions support push over HTTP+SSL? That's quite an obvious deployment option for Mercurial: set up the Web interface, configure the server for SSL and authentication, switch on push over the Web.

Defence in depth

cesarb — Mon, 26 Sep 2011 14:30:46 +0000

It is not just the kernel.

There are several classes of user-space exploits (/tmp races, setuid binaries, and so on) which are exploitable only if you have a shell or equivalent access.

Even if the kernel were 100% secure, you would still be increasing the attack surface by giving shell access.

SSH keys

clint — Mon, 26 Sep 2011 14:24:47 +0000

https://github.com/sitaramc/gitolite/blob/pu/doc/monkeysp...