Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

Bennett Haselton: Google+ To Gmail Controversy Missing the Point 244

Bennett Haselton writes "Google created controversy by announcing that Google+ users will now be able to send email to Gmail users even without having those Gmail users' email addresses. I think this debate misses the point, because it's unlikely to create a deluge of unsolicited email to Gmail users, as long as Google can throttle outgoing messages from Google+ users and terminate abusive accounts. The real controversy should be over the fact that Google+ users can search a public database of the names of all Gmail users in the first place. And limiting the ability of Google+ users to write to those Gmail accounts, won't do anything to address that." Read below to see what Bennett has to say.

Comment Re:here we go again... (Score 5, Interesting) 489

Because we want to get the best people. If you look worldwide, the gender balance (to pick the one imbalance your post mentions) is a lot closer to 50:50 in some countries, in others it's even more skewed. This implies that there's nothing intrinsic about women that makes them genetically less likely to want to do engineering or scientific things, there's some other cultural or social pressure stopping most of them. If we're only recruiting from 10% of the female population that, absent these pressures, would have gone into these subjects, then we can hope that it's the best 10%, but that's not very likely.

Comment Re:Get a real mail account (Score 1) 388

Nah, that's not a real solution. Not when you've had gmail since it's inception.

And the longer you keep using it, the harder it is to switch. I don't personally know anyone who has lost their GMail account, but I do for other mail providers (and Facebook), either because the provider decided they had violated some nebulous terms of service, they decided to start charging and kept pushing the price up, or they went out of business. If you like the GMail interface, then get the Google Apps for your Domain thing, buy a domain and point the DNS at Google, and at least then you can always point it somewhere else if you and Google stop wanting to do business.

Comment Re:You Must Be Crazy ... (Score 2) 139

Not necessarily. Most USB keyboards have firmware stored on a flash chip that has some spare capacity, and a lot have built-in USB hubs. There was at least one proof of concept for a keylogger that would record things to the on-board flash and then dump them to a specific USB device when it was inserted, then erase the on-board flash (rewriting the bit that contained some of the firmware) ready to start again.

Comment Re:feedback (Score 2) 139

The question that you should be asking is what happens if the browser is compromised. It doesn't matter if JavaScript is enabled, if some malware controlling your browser lets the attacker make arbitrary payments then your bank is doing it wrong. To pay anyone I've not paid before (and saved the credentials for) via Internet backing, my bank requires me to enter a code that they provide and the recipients account number and the amount in either a mobile phone app or a separate device, which then generates a code that I have to enter into the browser. If an attacker can compromise both my computer and my mobile device, then they can make arbitrary payments, but if they just compromise the browser they can't.

Comment Re:The correct way to "inform the authority" (Score 4, Insightful) 287

So this is the way that Snowden should have done it? I guess now we know that those who say "well, some good came from what he did, but he should have gone about it the right way".

We now know that there is no "right way" to deal with government, other than kick them in the ass.

Comment Re:Does it matter? (Score 1) 380

Microsoft, at least, creates a stable driver KBI for entire major OS versions. With Linux, you don't even get a guarantee of source compatibility across minor versions, so unless you upstream your driver it may be broken without warning (and if you do, the person 'fixing' it may not have access to the hardware, so will just compile test it). OS X also has stable KBIs for drivers, which are versioned to allow them to be incrementally deprecated and replaced. If you try to make life easy for vendors and they still don't produce drivers, then it ceases to be your fault.

Comment Re:Does it matter? (Score 1) 380

The thing I miss on OS X is the Altera tools for FPGA programming. You can get them to work on FreeBSD via some hacks, and they natively support Linux and Windows, but there's no Mac version.

Oh, and Parallels is the company that takes your money, gives you something that causes host kernel panics, and then tries to charge you more money for the version that doesn't do that. I'll stick with VirtualBox thanks. Parallels is never getting more money from me, after their staggering incompetence with Core 2 IPIs.

Comment Re:Lets not hope it's like the NHS IT disaster (Score 3, Informative) 266

The correct way of doing this sort of thing would have been to define standard formats for all of the information and produce a set of open source libraries for manipulating this data, then require every local medical authority to be able to produce and consume these formats. Each local authority could then take the open source reference implementation and add whatever ugly code they needed to interface with their legacy system. It doesn't matter whether they use the new formats internally, or just provide a mechanism for importing and exporting. Most likely, they'd initially do the latter, but when they started to replace existing systems they'd want to make native support for the standard formats a requirement.

Comment Re:Looks interesting - I have a few questions (Score 3, Informative) 71

Hi Sits,

How does this compare to existing (coarse grained) Linux capabilities?

Linux capabilities are not capabilities in the classical sense of unforgeable tokens of authority. They are just permissions. Linux capabilities allow a non-root process to do some things as if they were root. Capsicum implements a traditional capability model, where there is no ambient authority and a sandboxed process can not do anything unless it holds the relevant capability.

How does this compare to SELinux?

They address different goals and do so in different ways. The goal of SELinux (and the FreeBSD MAC framework's type enforcement mode) is to allow a system administrator to restrict access of a particular program or user (or program-user pair) to some subset of system resources. It is very bad for application compartmentalisation, because you can't fork() a process and have different permissions for the different children and it's difficult to update the permissions on the fly (although Apple does this with their port of the FreeBSD MAC framework, to implement sandboxing on OS X and iOS, allowing powerboxes to grant permission to specific files or directories).

Capsicum is intended for application sandboxing. It is assumed that the user trusts the binary to be non-malicious, but the program author does not trust his code to be free of exploitable bugs. A sandboxed process should call cap_enter() early on, at which point it can't create any new file descriptors. In some simple cases, that's enough. For example, a sandboxed version of man opens the file containing the mdoc sources and then calls cap_enter(). Even if it's run as root, and is reading a malicious source file that exploits the troff parser and allows arbitrary code execution, it can't do anything other than write text to the terminal. More complex applications will keep open a UNIX domain socket to a (more) privileged process that can pass in new file descriptors as they're needed, after doing some application-specific policy checking.

Does this complement things like Linux's seccomp?

Seccomp is far more restrictive than Capscium and prevents even harmless system calls (e.g. getpid(), gettimeofday() - although not on platforms where these use VDSO, I believe, but others of equal utility and harmlessness are blocked). Capsicum allows a whitelisted set of calls. Additionally, Capsicum adds finer-grained permissions on file handles (for example, you can be able to read, but not mmap, or append but not seek) and a set of at-suffixed system calls that work on directory descriptors, such as openat that allows a sandboxed process to open files in a directory that it holds the relevant capability for. This means that, for example, you can give a sandboxed browser tab process a directory descriptor to a cache directory and it can write cache data there without needing any interposition from a more privileged process. It talks directly to the kernel.

Seccomp-bpf extends seccomp by allowing system calls to be blocked or allowed based on the execution of a BPF filter. This is more expressive than Capsicum (Google's first port of Capsicum implemented it in terms of seccomp-bpf, although it was slow and not complete), but it doesn't allow the policies to easily associate permissions data with file descriptors and requires you to implement a complex BPF policy.

What's the overhead compared to the above?

There is basically no overhead for capsicum. It's one extra bitmask check on each system call that interacts with a file descriptor, which is in the noise for most workloads[1].

In terms of programmer overhead, there's a summary table for the number of lines of code changed to implement sandboxing with various mechanisms in Chrome in the original Capsicum paper. Here's the short version:

  • Windows ACLs: 22,350
  • Chroot: 605
  • OS X Seatbelt (built atop the FreeBSD MAC framework, which was also written by Robert): 560
  • SELinux: 200
  • Linux seccomp: 11,301
  • Capsicum: 100

This doesn't tell the whole story, because the SELinux policy in Chrome periodically got out of sync with the code, and they only got errors when it was too restrictive, not when it was too permissive, so a few releases shipped without enough sandboxing. The seccomp version could isolate renderer processes from each other, but the SELinux one couldn't. The seccomp implementation did not adequately restrict filesystem access, and neither seccomp nor SELinux adequately restricted IPC access. You can see Robert's thesis for more detailed explanation of the limitations of all of these.

Will FreeBSD ship a policy for a ssh/sshd?

I think we will in 10.1, but not in 10.0. The privsep code in OpenSSH is quite special. Another colleague of Robert and myself has been developing a tool to aid reasoning about application compartmentalisation (SOAAP) and has been applying it to Chromium and OpenSSH: Chromium is easier to understand. We are shipping with a number of other utilities using Capsicum in 10, and more will in 10.1.

[1] The initial implementation made capabilities special file descriptors that referred to other file descriptors, so the numbers in the original paper are slightly worse, but still very small.

Comment Re:OMG! (Score 2) 71

There are a few big differences. The first is that SELinux is really an extension of the ACL approach: you have a big matrix with things that can do stuff, and things that can have stuff done to them, and a bit in each position indicating whether that combination is allowed. SELinux (and most ACL implementations) compress this, because a matrix with one row for every process-user pair and one column for every filesystem or kernel object would be huge. The goal of things like SELinux is for system administrators to be able to restrict the rights of certain things.

The goal of Capsicum is different. It's not intended to protect against malicious code, it's intended to protect against exploitable code. This is why, for example, Chromium splits itself into separate processes and tries to isolate them from the rest of the system: if one renderer hits something that triggers an exploit, the attacker shouldn't be able to take control of anything other than that page. Unfortunately, with SELinux, there's no way of isolating two processes that are instances of the same program and running as the same user from each other. This is because SELinux was never designed for application compartmentalisation.

When a program that's been compartmentalised using Capsicum starts, it enters capability mode with the cap_enter() system call. At this point, it can't create any new file descriptors and can only issue a whitelisted set of system calls that don't touch the global namespace. File descriptors become capabilities, in the classical sense: they're unforgeable tokens of authority, and the only way that the sandboxed process can communicate with the world outside. If you compromise a process that's sandboxed in this way, you can only access the file descriptors that it can access, and for something that's expecting to deal with untrusted data, this is likely to only be a socket for talking to the more privileged process, maybe a network socket to the server, and possibly a directory handle to a cache directory.

Of course, it's not a panacea. Capsicum sandboxed processes can still be susceptible to the confused deputy problem. They can receive new file descriptors (capabilities) via UNIX domain sockets from a more privileged process, and if they can persuade such a process to open something on their behalf that they shouldn't have then they can still elevate privilege. As with other mitigation techniques, it's all about making life harder for the attacker.

In FreeBSD 10, we're shipping a number of base system utilities that run in sandboxed mode by default, and a few more are currently being tested and should appear in 10.1. We're also including a friendly daemon called Casper that will provide services (e.g. DNS lookups) to sandboxed processes, without giving them the rights to create sockets.

Slashdot Top Deals

Whenever people agree with me, I always think I must be wrong. - Oscar Wilde