Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Cambridge's Capsicum Framework Promises Efficient Security For UNIX/ChromeOS

timothy posted more than 2 years ago | from the sounds-spicy dept.

Google 87

An anonymous reader writes "Communications of the ACM is carrying two articles promoting the Capsicum security model developed by Robert Watson (FreeBSD — Cambridge) and Ben Laurie (Apache/OpenSSL, ChromeOS — Google) for thin-client operating systems such as ChromeOS. They demonstrate how Chrome web browser sandboxing using Capsicum is not only stronger, but also requires only 100 lines of code, vs 22,000 lines of code on Windows! FreeBSD 9.0 shipped with experimental Capsicum support, OpenBSD has patches, and Google has developed a Linux prototype." While the ACM's stories are both paywalled, the Capsicum project itself has quite a bit of information online in the form of various papers and a video, as well as links to (BSD-licensed) code and to various subprojects.

cancel ×

87 comments

Sorry! There are no comments related to the filter you selected.

spicy! (0)

noh8rz2 (2538714) | more than 2 years ago | (#39161271)

did you know that capsicum is the chemical that makes chilly papers hot?I think it's a goo d metaphor for the protection!

Re:spicy! (5, Informative)

gstrickler (920733) | more than 2 years ago | (#39161371)

Did you know that you're incorrect? Capsicum [wikipedia.org] is the genus of the plants, capsaicin [wikipedia.org] is the chemical.

Re:spicy! (2)

PatPending (953482) | more than 2 years ago | (#39161395)

And he also doesn't know chilly != chili and papers != peppers.

Re:spicy! (0)

Anonymous Coward | more than 2 years ago | (#39161475)

And pepper != capsicum

Pepper is the spice, capsicum is the fruit. It's too confusing when foreigners like Americans use it incorrectly.

Re:spicy! (-1)

Anonymous Coward | more than 2 years ago | (#39161523)

"foreigners like Americans"

That's funny, posting that on a U.S.A. website.

(Captcha: posted)

Re: Dear Tubby Lardass Fatbodies (SpicyLikeFood!) (-1)

Anonymous Coward | more than 2 years ago | (#39161769)

Your fat is something you did to yourself because you have no self-respect and are too fucking lazy and undisciplined to put the fork down long enough to lose weight. You are fat because you eat too much. You eat more calories than you burn and that's too much. It's so simple a retarded dog could understand it without needing it explained to him. You fail at life because you fail to execute such a simple idea. You are a glutton, a lard-lover, a bottomless stomach that is never satisfied because your self-hatred means there is never enough comfort food. Fuck you.

Maybe you will choke on the next pork rind you eat and save the taxpayers a ton of healthcare costs.

Re: Dear Tubby Lardass Fatbodies (SpicyLikeFood!) (0)

Anonymous Coward | more than 2 years ago | (#39161835)

Please pass the salt.

Re:spicy! (1)

noh8rz2 (2538714) | more than 2 years ago | (#39164307)

did you know, considering i defined the meme / phrasing for the entire thread, I deserve to be modded up!

Re:spicy! (0)

hairyfeet (841228) | more than 2 years ago | (#39162663)

Did you know its kind of pointless as ChromeOS is a giant fail? Oh while I'm sure the OS is just fine if its anything like Android, the problem is that the ODMs slapped it on underpowered hardware and then slapped a "ZOMFG! What are they thinking?" pricetag on it! Hell they wanted nearly $550 for the Samsung? its a fricking Atom! You could buy either a full size laptop OR a MUCH nicer netbook for much less and actually have more functionality?

ChromeOS might have had a chance if they'd only known what to do with it, it should have been the OS of a $150 ARM dual core netbook. Google should have sold it at cost with the data mining locked in so the user couldn't change it and then raked in the cash as users would happily give up their privacy for a sub $200 laptop, instead they picked OEMs that tried to jack the living hell out of the price so badly you'd have thought it was made by a certain fruit company.

Finally sadly security can't be solved by tech, well not unless you can cook up something that shocks the shit out of the user and says "WTF are you doing? Stop that!" when they do something incredibly stupid which is often. You can get the average user to give you more than enough info for identity theft simply by offering a drawing for a free iPad. No matter how many times I warn people that TINSTAAFL you'd be amazed at how many will run any executable, fill out any form, jump through any hoop for the chance at 'free' stuff. They can lock down the OS all they want. Its the data that's worth money now, the OS? not so much.

Re:spicy! (1)

TheRaven64 (641858) | more than 2 years ago | (#39163127)

Did you know its kind of pointless as ChromeOS is a giant fail?

Did you know that ChromeOS (a Linux-based OS) is completely irrelevant in an article about a FreeBSD feature that is now used in Chromium (a web browser)? The only vague relevance is that one of the people mentioned in TFS works on both the Chrome / Chromium and ChromeOS projects. But don't let that get in the way of a good anti-Google rant.

Re:spicy! (1)

hairyfeet (841228) | more than 2 years ago | (#39163331)

Actually I was originally FOR ChromeOS as i thought it was a brilliant idea for clueless home users. An OS that will protect them by basically running everything on the server and thus get rid of local exploits. As for Chrome, why should we care exactly? Unless you are running XP (or Linux) you have low rights mode which by default has lower permissions than users which makes it pretty damned hard to infect a machine anyway. i know as i tried to infect a machine that I planeed to wipe anyway and went to every topsite and crapsite i could find and...nothing, zip nada squat.

So its a thing for software that doesn't need it except for old OSes or niche OSes...wow, great, thanks.

Re:spicy! (1)

starfishsystems (834319) | more than 2 years ago | (#39166595)

Finally sadly security can't be solved by tech, well not unless you can cook up something that shocks the shit out of the user and says "WTF are you doing? Stop that!"

I'm responding not to give you personally a hard time but because you've expressed a common misperception that seems peculiar to the personal computer generation.

Certainly security can be solved by tech, for many important classes of security and with many types of technology. What's a bank vault, for example?

In terms of information security, there are again many important classes of security that have been effectively realized. Those of us who grew up with mainframe architectures understand this from firsthand experience. If your only access to a system is through a particular application, your attack surface is limited to the functionality and privileges of that application. The choice of technology can indeed make this system secure. Electric shocks are not required.

Now consider distributed applications. For example, there is a server somewhere waiting for network connections from clients. With respect to the server, your attack surface is again limited to the functionality and privileges of the application, in this case the network service. With reasonable effort, technology can secure this server. The network protocol presents a different target and likewise a different attack surface. If we want to secure the protocol then we have to be concerned with how to reliably identify clients, mitigate denial of service attacks, preserve confidentiality of data in transit, and so on. This is harder than the mainframe problem but, given reasonable criteria, can also be solved technologically.

When we turn to something like a personal computer, a completely different situation prevails. It's easy, almost trivial, to build a fully-functioning personal computer from off-the-shelf components. There is nothing to stop you from building an arbitrarily insecure system. Without exception, all credible DRM schemes are based on functionality baked into one or more of these components, such that you can't build a working system without them. (I'm not an advocate of DRM, just saying that this is the only indefeasible way to implement it.)

See, it all depends on who owns the system. You can't generalize the particular circumstances of personal computer ownership to computing in general, let alone to technology as a whole.

our first solid metric (5, Funny)

Xtifr (1323) | more than 2 years ago | (#39161281)

So, we have our first solid metric: it's 220 times as hard to make Windows secure as it is for BSD or Linux.

(Xtifr runs and hides before the angry crowd of humorless astroturfers with mod points arrives.) :)

Re:our first solid metric (1)

nerdyalien (1182659) | more than 2 years ago | (#39161609)

one liner is more than enough for any OS....

>> shutdown

Re:our first solid metric (-1)

Anonymous Coward | more than 2 years ago | (#39161739)

one liner is more than enough for any OS....

>> shutdown

Win7:
    C:\> shutdown
    Usage: shutdown [/i | /l | /s | r | /g | /a | /p | /h | /e] [/f] ...50 odd lines cut
    C:\>

MacOS X:
    # shutdown
    shutdown: NOT super-user
    # sudo shutdown
    usage: shutdown [-] [-h [-u] [-n] | -r [-n] | -s | -k] time [warning-message ...]
    #

Linux:
    # shutdown
    shutdown: you must be root to do that!
    Usage: shutdown [-akrhPHfFnc] [-t sec] time [warning message] ...10+ lines cut
    #

Win98:
    C:\> shutdown
    'shutdown' is not recognized as an internal or external command,
    operable program or batch file.
    C:\>

FreeBSD:
    # shutdown /sbin/shutdown: Permission denied.
    # sudo shutdown
    usage: shutdown [-] [-h | -p | -r | -k] [-o [-n]] time [warning-message ...]
    #

Given the above, I hereby declare the parent wrong. :)
Also, don't ask about Win98. Please.

Re:our first solid metric (1)

BRTB (30272) | more than 2 years ago | (#39161807)

So.... why Win98? :)

Re:our first solid metric (0)

Anonymous Coward | more than 2 years ago | (#39162391)

MacOS X:

    # shutdown

    shutdown: NOT super-user

    # sudo shutdown

    usage: shutdown [-] [-h [-u] [-n] | -r [-n] | -s | -k] time [warning-message ...]

    #

Linux:

    # shutdown

    shutdown: you must be root to do that!

    Usage: shutdown [-akrhPHfFnc] [-t sec] time [warning message] ...10+ lines cut

    #

FreeBSD:

    # shutdown /sbin/shutdown: Permission denied.

    # sudo shutdown

    usage: shutdown [-] [-h | -p | -r | -k] [-o [-n]] time [warning-message ...]

When you prefix commands with '#', it typically indicates that you are running as root already. When you wish show that the command is intended to be run as a regular user, you can use the '$'-prefix.

Also, in at least Linux (not sure about OSX or FreeBSD, as I haven't used either), you can simply type

        # shutdown now

to shutdown your computer. Four additional characters still makes it way simpler than in WIndows. If you feel that "shutdown" is too difficult to type, the following command also works

        # halt

Re:our first solid metric (1)

philip.paradis (2580427) | more than 2 years ago | (#39163505)

When you prefix commands with '#', it typically indicates that you are running as root already.

When I prefix commands with '#', it typically means I'm using sh or bash, and they're actually comments ;).

Re:our first solid metric (1)

CoolGopher (142933) | more than 2 years ago | (#39161757)

one liner is more than enough for any OS....
 
>> shutdown

Win7:
        C:\> shutdown
        Usage: shutdown [/i | /l | /s | r | /g | /a | /p | /h | /e] [/f] ...50 odd lines cut
        C:\>

MacOS X:
        # shutdown
        shutdown: NOT super-user
        # sudo shutdown
        usage: shutdown [-] [-h [-u] [-n] | -r [-n] | -s | -k] time [warning-message ...]
        #

Linux:
        # shutdown
        shutdown: you must be root to do that!
        Usage: shutdown [-akrhPHfFnc] [-t sec] time [warning message] ...10+ lines cut
        #

Win98:
        C:\> shutdown
        'shutdown' is not recognized as an internal or external command,
        operable program or batch file.
        C:\>

FreeBSD:
        # shutdown /sbin/shutdown: Permission denied.
        # sudo shutdown
        usage: shutdown [-] [-h | -p | -r | -k] [-o [-n]] time [warning-message ...]
        #

Given the above, I hereby declare the parent wrong. :)
Also, don't ask about Win98. Please.

Re:our first solid metric (0)

Anonymous Coward | more than 2 years ago | (#39162299)

On linux you probably want "halt" or alternately, "reboot". The full "shutdown" command lets you do fancy things like set the system to power off in 3 hours and 30 minutes, with warnings sent out to all users logged in, and stuff like that.

Re:our first solid metric (1)

hobarrera (2008506) | more than 2 years ago | (#39170451)

PLEASE read the man pages. You couldn't have been more wrong!

Re:our first solid metric (1)

metrix007 (200091) | more than 2 years ago | (#39276071)

He is 100% right.

Re:our first solid metric (1)

hobarrera (2008506) | more than 2 years ago | (#39276329)

halt and reboot, in unix (and also in linux in the past), would inmediantely halt or reboot. No informing users, killing processes, etc, just HALT.
Shutdown on the other hand, informed users, first sent sigint, and then sigkill, etc. It was the "friendly" choice, and gave processes a chance to exit gracefully and save anything they should.

Since so many users where using halt and shutdown -h as if they were the same, most linux distros have adapted the behaviour to what those users (who had not read the manpages) expected. Depending on what OS you use, the manual may describe this.

Re:our first solid metric (4, Interesting)

TheRaven64 (641858) | more than 2 years ago | (#39163145)

So, we have our first solid metric: it's 220 times as hard to make Windows secure as it is for BSD or Linux.

BSD or Linux? Check the paper [cam.ac.uk] . It took 100 lines of code with Capsicum, 200 with SELinux, 605 with Linux-with-chroot, 11,301 with Linux-with-seccomp and 22,350 with Windows. So (with your metric) it is somewhere between 2 and 10 times as hard to make Windows as secure as Linux and between 2 and 10 times as hard to make Linux as secure as FreeBSD. And the best score for Linux - the SELinux sandbox - requires enabling SELinux which is a massive blob of code and has introduced several of its own security holes in the last couple of years, while Capsicum is much simple and easier to audit.

Re:our first solid metric (1)

Xtifr (1323) | more than 2 years ago | (#39165355)

See, to post your fact-filled response, you actually had to RTFA, and you had to take my silly post seriously. To post my silly joke, I only had to read the slashdot summary. I win! :)

BTW, check your math. It's between 2 and 100 times for Win v Linux, not between 2 and 10. 22,350 is more than 100 times greater than 200. Likewise, it's between 2 and 100 with Linux v BSD. Also, chroot is part of GNU coreutils, so with a stock, vanilla GNU/Linux system, the answer seems to be 605, which means the normal, default factor is 36 between Win and Linux, and 6 between Linux and BSD.

And I still haven't glanced at TFA, or made a serious suggestion anywhere. :)

Android? (1)

Anthony Mouse (1927662) | more than 2 years ago | (#39161325)

This sounds like something that could be useful for Android apps.

Re:Android? (4, Interesting)

Anonymous Coward | more than 2 years ago | (#39161563)

It may sound that way, but it doesn't read that way. Perhaps if you stopped listening to articles and read the written words you'd know what they were about.

Specifically, Capsicum is a Unix (and therefore heavily C- and process-based) framework for sandboxing applications. Android applications, on the other hand, are written in Java and executed on the Dalvik VM. The "process" model is completely different from that of Unix. C applications and modules in Android can only use and link against the NDK, which doesn't expose any operating system interfaces at all. So, again, Capsicum is useless.

Capsicum also debuted, like, years ago. I doubt it will pick up steam because the necessary underpinnings will never be adopted in the Linux kernel. For one thing, anything which comes from FreeBSD always has to be re-engineered, and usually poorly. It hardly matters that the Capsicum researchers chose FreeBSD as their test bed for probably arbitrary reasons. What matters is that FreeBSD has now infected it.

Second, there are two interest groups in the Linux community that dictate security frameworks: the SELinux people and the anti-SELinux people. The anti-SELinux folk are already wedded to a host of alternatives. Capsicum will have a cold reception.

Re:Android? (2, Informative)

PatPending (953482) | more than 2 years ago | (#39161655)

Capsicum also debuted, like, years ago.

And appears to be stale:

The website hasn't been updated since 2010.

The latest GitHub [github.com] code is from 2010.

The "Documentation and Publications [cam.ac.uk] " are from 2009 and 2010

Re:Android? (0)

Anonymous Coward | more than 2 years ago | (#39161765)

I read some time ago that the FreeBSD guys intended to add Capsicum capability to a bunch of software once they integrated it in the system. Anyone has more info?

From BSD Magazine (3, Informative)

unixisc (2429386) | more than 2 years ago | (#39162765)

Here is what BSD magazine described as the Capsicum implementation in FreeBSD:

Capsicum is a lightweight framework which extends a POSIX UNIX kernel to support new security capabilities and adds a userland sandbox API. It was originally developed as a collaboration between the University of Cambridge Computer Laboratory and Google, sponsored by a grant from Google, with FreeBSD as the prototype platform and Chromium as the prototype application. FreeBSD 9.0 provides kernel support as an experimental feature for researchers and early adopters. Application support will follow in a later FreeBSD release and there are plans to provide some initial Capsicum-protected applications in FreeBSD 9.1.

Traditional access control frameworks are designed to protect users from each other through the use of permissions and mandatory access control policies. However, they cannot protect the user when an application, such as a web browser, processes many potentially malicious inputs, such as HTML, scripting languages, and untrusted images. Capsicum provides application developers fine-grained control over files and network sockets to provide privilege separation within an application, with minimal code changes. In other words, it provides application compartmentalisation, allowing the application itself to provide many different sandboxes to contain its various elements. As an example, each tab in the Chromium browser has its own sandbox; it is also possible to contain each image in its own sandbox. Creating sandboxes under Capsicum does not require privilege, a key problem with current UNIX sandbox approaches.

As an example, the insecure tcpdump application can be sandboxed with Capsicum in about 10 lines of code and the Chromium web browser can be sandboxed in about 100 lines of code. capsicum(4) provides an overview of the available system calls. More information, including links to technical publications, projects, and a mailing list, can be found at the Capsicum website [cam.ac.uk] .

Re:Android? (1)

Anonymous Coward | more than 2 years ago | (#39162083)

Capsicum also debuted, like, years ago.

And appears to be stale:

The website hasn't been updated since 2010.

The latest GitHub [github.com] code is from 2010.

The "Documentation and Publications [cam.ac.uk] " are from 2009 and 2010

So stale it got imported into the base system and kernel newest release of FreeBSD.

Besides, they've proven the system works, what else is really needed? It will take time to change userland utilities to use it, and only at that point will there perhaps be a need to add more capabilities for use cases that may not have been thought of. As it is, I'd be hard pressed to think of a program more complicated than a web browser (network, disk, IPC, and UI access all needed in varying degrees).

Re:Android? (1)

Anonymous Coward | more than 2 years ago | (#39162911)

Looks like their web site got updated after this article got posted: http://www.cl.cam.ac.uk/research/security/capsicum/ -- they have working group slides from October 2011, and news flashes from both January and February 2012, including Communications of the ACM articles are definitely from 2012! However, it sounds like the hard part is yet to come -- getting APIs into operating systems is the beginning, not the end, of the story.

Re:Android? (5, Informative)

TheRaven64 (641858) | more than 2 years ago | (#39163155)

Disclaimer: I am a FreeBSD developer, and was visiting cl.cam.uk last week.

Capsicum is very much under active development. It's being used in Cambridge in several projects, funded by DARPA and Google. It is no longer developed on github because it is now merged upstream into FreeBSD. As TFS said, it is part of FreeBSD 9, and the core FreeBSD utilities are slowly being modified to use it (it's easy to incrementally deploy capsicum). If you want up to date documentation, check the man pages.

Re:Android? (1)

Anthony Mouse (1927662) | more than 2 years ago | (#39161691)

C applications and modules in Android can only use and link against the NDK, which doesn't expose any operating system interfaces at all.

I doubt it will pick up steam because the necessary underpinnings will never be adopted in the Linux kernel.

And, of course, a good concept with an incompatible implementation could never, ever be reimplemented to work on a different operating system or programming language.

Re:Android? (1)

js_sebastian (946118) | more than 2 years ago | (#39161941)

C applications and modules in Android can only use and link against the NDK, which doesn't expose any operating system interfaces at all.

I doubt it will pick up steam because the necessary underpinnings will never be adopted in the Linux kernel.

And, of course, a good concept with an incompatible implementation could never, ever be reimplemented to work on a different operating system or programming language.

The point is that if you are programming in java, you can offer arbitrary security models to applications running inside the VM, without the need for any special operating system support. The hard part is enriching the security model in a useful and backwards-compatible way for applications that run natively on the hardware, which is what capsicum does.

Re:Android? (2)

tal197 (144614) | more than 2 years ago | (#39162795)

The Java equivalent of Capsicum is Joe-E: http://code.google.com/p/joe-e/ [google.com]

Re:Android? (2)

TheRaven64 (641858) | more than 2 years ago | (#39163221)

The point is that if you are programming in java, you can offer arbitrary security models to applications running inside the VM, without the need for any special operating system support

This is true if and only if your JVM is 100% bug free. Do a CVE search for JVM, Flash, or JavaScript to see how likely that is. With Capsicum, the JVM can restrict itself to the capabilities that the Java code should have, so even if the VM itself is compromised, the Java code can't escape from the sandbox.

Re:Android? (1)

bgat (123664) | more than 2 years ago | (#39161719)

Android applications, on the other hand, are written in Java and executed on the Dalvik VM. The "process" model is completely different from that of Unix.

First sentence is true, second one isn't. To wit, Android Activity classes run under Dalvik, which itself runs as an ordinary Linux process. Moreover, Android makes extensive use of the Linux process model as part of its security system.

You don't escape the Linux process model simply by wrapping a large application framework like Android around your code. The only way to escape the Linux process model is to not run as a Linux process e.g. run in kernel space.

Re:Android? (0)

Anonymous Coward | more than 2 years ago | (#39161867)

By that logic you're already running in kernel space. And because kernel space has access to privileged CPU instructions, you have full system access.
I suppose that's true in a narrow sense, but of no matter.

Android uses Linux processes, yes. But the Unix process abstraction isn't in the toolbox of Android applications. The process model is different in Android, and Capsicum is inconsequential. The low-level details of Capsicum aren't new or novel. The usefulness comes in how it packages those details--the abstractions--in the context of Unix application development; namely, the kernel API and the user-space API.

Re:Android? (2)

jaymemaurice (2024752) | more than 2 years ago | (#39162067)

For one thing, anything which comes from FreeBSD always has to be re-engineered, and usually poorly. It hardly matters that the Capsicum researchers chose FreeBSD as their test bed for probably arbitrary reasons. What matters is that FreeBSD has now infected it.

God forbid they release and modify truly free code that can be taken and be further modified, then sold without risk of litigation from the original author* If anything, unless I missed the sarcasm, I think it was wise to not infect the project with GPL or taint it early by trying to make it compatible with everything maintained seperately rather then a single released package that is FreeBSD. The poor re-engineering is what makes L \edd\eiWere you trying to be flamebait there?!

Re:Android? (0)

Anonymous Coward | more than 2 years ago | (#39162193)

Hear this man.

Btw, even full blown unix security is tricky. The sole promise of a single solution is already a sign of cluelessnes

Re:Android? (0)

Anonymous Coward | more than 2 years ago | (#39162545)

>The sole promise of a single solution is already a sign of cluelessnes
I think the developers are well aware of the history of *nix security mechanisms and are looking for a practical approach to improve things. They're certainly not clueless; of interest is whether capsicum gains traction.

As one person noted:
"Capabilities are a great fit for sand-boxing; by restricting which capabilities have been granted to an OS process, it is possible to constrain that process to access only the resources it actually requires. For example, a Web browser could be designed to launch a process for each Web page the user has open, and to use capabilities to sandbox each browser process, granting it the ability to access cached data and cookies associated with the page, but preventing it from accessing data from other sites or the user's desktop.

The major challenge the authors face is preserving Unix's existing APIs, legacy applications, and performance, while simultaneously providing a path for developers to take advantage of the strong compartmentalization and sandboxing potential of capabilities. To have impact, Capsicum needs to provide developers with an incremental adoption path; it should be easy to create sandboxes, to identify the resources to which the sandbox requires access, and to take an existing codebase and make minimal changes to it to use capabilities and sandboxed environments."

Re:Android? (0)

Anonymous Coward | more than 2 years ago | (#39162243)

> It hardly matters that the Capsicum researchers chose FreeBSD as their test bed for probably arbitrary reasons
just maybe because Robert Watson intimately knows FreeBSD being a major developer in the project

If only.. (1)

dutchwhizzman (817898) | more than 2 years ago | (#39162595)

Android applications get almost no shielding from the OS and filesystem. security separation is based on UID and file system permissions. Since most apps are seriously lacking in file system permissions (app developers just turn on permissions for everyone, so their app works) and things like immutable files and ACLs aren't used, in practice Android is about as safe as an unpatched Windows ME machine directly connected to the Internet (slightly exaggerated for theatrical purposes). I wouldn't trust my company or private data to Android without some serious frameworks in place, that aren't there now.

Re:Android? (2, Informative)

Anonymous Coward | more than 2 years ago | (#39162839)

How does something like this get modded up? OP know exactly two things here, jack and shit.

First, any trivial amount of searching would reveal that Robert Watson, author of Capsicum, is pretty much the FreeBSD project lead, and has been for a very long time. His reasons weren't arbitrary, this is a technology deliberately designed for FreeBSD. This is also not the same as SELinux. Robert Watson already wrote that 10 years ago when he worked on TrustedBSD. This is application level sandboxing, not system level MAC.

And yes, Capsicum was started "years ago." From concept to delivery, stuff like this takes time. It's finally seeing light officially for-the-rest-of-us in FreeBSD 9 which was released last month.

Finally, how will Linux people adopt it? FreeBSD people don't care. That's the beauty of being not-Linux.

Re:Android? (0)

Anonymous Coward | more than 2 years ago | (#39163023)

What would prevent a C application from invoking a system call? You don't need to link to anything to do it through inline assembly, or through a buffer overflow in system library code if necessary.

Re:Android? (3, Informative)

TheRaven64 (641858) | more than 2 years ago | (#39163179)

In UNIX, everything that interacts with anything outside of the process goes via file descriptors. Capsicum provides special file descriptors with capabilities. When you enter capability mode, the kernel no longer allows you to create new arbitrary file descriptors. This means you can't create new sockets, you can't touch the filesystem, and you can't touch any devices. You are completely isolated unless some other process passes you a file descriptor or you create one via a set of special rights. For example, if you have the correct permission, you can use open_at() to create a new file in a directory for which you have a descriptor. This allows you to, for example, set up a sandbox where an application can store files in a per-application location and can use a temporary directory. If it wants to open a socket, it has to ask another process. If it wants to open other files, it has to ask another process. The typical way of handling the second is to have a file-chooser application that allows the user to select files and then passes the rights to access them into the sandbox.

Re:Android? (0)

Anonymous Coward | more than 2 years ago | (#39163381)

Thanks, I get that about Capsicum, but clearly my question was misleading: I wanted to know why Capsicum would supposedly be useless on Android, i.e. what would prevent a random Android process from invoking a system call if there are no capabiliy checks?

Re:Android? (1)

TheRaven64 (641858) | more than 2 years ago | (#39163621)

Then I don't understand the question. Capsicum is a kernel extension. It checks capability rights on file descriptors in the kernel. Nothing stops the process from making system calls - that's the point. Capsicum just stops certain system calls from doing anything...

Re:Android? (1)

Anthony Mouse (1927662) | more than 2 years ago | (#39164113)

I think the question is, why would it be "useless" for apps on Android (assuming it was implemented in Linux), if the virtual machine itself is subject to the same capabilities when it tries to do system calls for apps? That would seem to work fine.

Of course, the possibility exists that the AC is full of crap, but I'll defer to someone who might actually know rather than just speculating as I am.

Re:Android? (1)

TheRaven64 (641858) | more than 2 years ago | (#39164373)

Ah, I misunderstood the original claim. The original AC seems to think that only linking to the NDK means that you can't do anything malicious, which the second AC points out is nonsense because it can still do anything it wants by issuing system calls directly. I think Android does some chroot() stuff to ensure that NDK applications can't do this (they can only access most of the system by going via Dalvik). That said, if Android used FreeBSD, Capsicum could be used to enforce the Dalvik permissions at the OS level. This would mean that a bug in Dalvik that let a malicious application run arbitrary code would no longer mean a security compromise, it would just make the app crash.

Re:Android? (0)

Anonymous Coward | more than 2 years ago | (#39164431)

Exactly, thank you very much. -The second AC

Re:Android? (1)

DarkOx (621550) | more than 2 years ago | (#39165881)

It would work yes, but it would provide no granularity. So there would be little if any added security. I suppose you *might* identified some calls user land software of the type installed on a cell phone or tablet should *never* need to do and disable those but that is such a finite number other approaches to that likely make more sense.

Re:Android? (1)

gnud (934243) | more than 2 years ago | (#39163227)

When a process does a system call, the control goes to the kernel. The kernel looks up the capabilities of the process that made the call, and actually, you know, uses them.

Re:Android? (1)

Chrisq (894406) | more than 2 years ago | (#39163093)

It may sound that way, but it doesn't read that way. Perhaps if you stopped listening to articles and read the written words you'd know what they were about.

Specifically, Capsicum is a Unix (and therefore heavily C- and process-based) framework for sandboxing applications. Android applications, on the other hand, are written in Java and executed on the Dalvik VM. The "process" model is completely different from that of Unix. C applications and modules in Android can only use and link against the NDK, which doesn't expose any operating system interfaces at all. So, again, Capsicum is useless.

Capsicum also debuted, like, years ago.

I agree this will add nothing at an app level. However if it is sufficiently lightweight and powerful in could conceivably be used at an OS level below the Dalvic JVM,

Device security vs. data security (0)

Anonymous Coward | more than 2 years ago | (#39162925)

What is the meaning of having the MOST secure device in the world, if all your data and everything you do flows to the company whose product you are?

Sounds good to me! (-1)

Anonymous Coward | more than 2 years ago | (#39161369)

Did you ever know a "chocoholic"? One of those folks who just can't get enough chocolate? I bet there's at least one in your home or workplace. At my house, it's my wife Emily. She's got to have her little bowl of Hershey's Kisses in the living room. She can't go shopping without bringing home some chocolate ice cream or a chocolate-cake mix. She's even got a funny little sweatshirt that says, "My Name Is Emily, And I'm A Chocoholic."

To be honest, I'm a bit of a chocoholic myself. Except for one small detail. You see, instead of being addicted to chocolate, I'm addicted to booze. Yep, from dawn to dusk, there's one thing on my mind: booze! Beer, liquor, wine, all that stuff!

When my wife gets one of her cravings, she reaches for a Baby Ruth or Mars bar. With me, it's Icehouse beer. My refrigerator is always stocked with plenty of it. I also have a little flask of whiskey in my desk drawer at work. In fact, if you can keep a secret, I even keep some booze in my car in case of traffic jams. I just can't stand to be without booze for too long!

I'm a lot like that Cookie Monster on Sesame Street. Only it's more like the Booze Monster. When I walk into a party and see that they have booze of any kind, it's like, "Whoa-hoa! All bets are off! Lemme at that booze!"

I remember this one time, there was no chocolate in the house. Emily was going out of her mind, trying to scrape up some sort of chocolate fix. In the end, she resorted to drinking a cup of hot cocoa. It was so cute! Sort of like the time I drank all her hairspray because there was no booze in the house. Or that other time with the rubbing alcohol. Or the Nyquil. Or the Aqua-Velva.

Another time, I was completely out of booze, and all the stores and bars were closed, so I drove 45 minutes to find a place that would sell me some beer or something. I was kind of embarrassed, because here it was late Monday night, and I had to work the next day, and I'm driving around looking for booze. But, hey, that's just how things are when you're a "booze-oholic" like me! I finally found a huge all-night liquor store. You should have seen how I loaded up! Cases of this, fifths of that. It was 5 a.m. when I finally got home, so I just said, "To heck with work!" and had my own little improvised holiday. I called it Booze Day! I'd been working hard, getting to work on time almost every day for two weeks, so I figured I'd earned what wound up being the rest of the week off.

Sometimes Emily and I think we should cut down a littleâ"you know, health concerns and all. But there's always some special occasion that gives us an excuse to go off our "diets." Halloween was Emily's last big bender. We only got three trick-or-treaters the entire night, so the whole big bowl of Reese's Peanut Butter Cups went straight to her. (Or straight to her thighs, as she said!)

My most recent bender was today. There was a good movie on TV, and I figured, hey, I'll need steady hands to change the volume. Of course, it all went straight to my liver, but what are you gonna do?

For my birthday, Emily gave me the funniest coffee mug, perfect for Irish coffee. It has a little teddy bear on it with a "don't mess with me" look on his face, and it says, "Hand Over The Booze And Nobody Gets Hurt." I laughed so hard! That bear was just like me when I robbed the party store earlier this year! Also, the mug is really big, so it can hold a lot of booze... another plus!

Yes, those chocoholics are a funny sort. But they won't hurt youâ"as long as they have their chocolate, that is. Or, in my case, booze!

Re:Sounds good to me! (1)

DMFNR (1986182) | more than 2 years ago | (#39161561)

What is this like some kind of AA for nerds? Alcoholics Anonymous Cowards? The first step is admitting you have a problem... on Slashdot!

Re:Sounds good to me! (1)

retchdog (1319261) | more than 2 years ago | (#39161961)

i think it's supposed to be ironic. the reader's relief that it's not about anal rape and/or eating feces, like most copy-paste jobs, plays into the light-heartedness of the self-destruction.

Apps hard to secure... (4, Interesting)

Anonymous Coward | more than 2 years ago | (#39161513)

The paper goes to great length to point out that applications can only be as secure as the operating system lets them. In section 5 of the A Taste of Capsicum: Practical Capabilities for UNIX paper the authors talk about how Chrome has been secured in all the major operating systems. They succulently sum up the great lengths Google has gone to, to make Chrome secure. Then promptly shoot holes in each of the approach's. Windows gets the worst treatment (lack of capabilities), followed by Linux (complicated approach's.) The authors give the best marks to FreeBSD and then to the Mac OS X MAC implementation.

The point I took away from the paper was, who ever has the most complete and easiest to implement sandbox (MAC, DAC) implementation to take advantage of can have the most secure applications. But at the end of the day its still up to the developer to take advantage of those capabilities.

Re:Apps hard to secure... (1)

TheRaven64 (641858) | more than 2 years ago | (#39163187)

But at the end of the day its still up to the developer to take advantage of those capabilities.

True, although there are some ways around this. For example, you can quite easily with capscium create an application launcher that opens a set of file descriptors and then execs an untrusted application. It's also relatively easy to integrate this functionality into a filesystem browser or application launcher, so if you try to run an application that is not on a whitelist it will run it in a sandbox. This is likely to appear by default around FreeBSD 10.0.

Re:Apps hard to secure... (1)

Anonymous Coward | more than 2 years ago | (#39163495)

Windows has capabilities, they are called policies.
http://support.microsoft.com/kb/310791

And since Windows 7, AppLocker is also available,
http://technet.microsoft.com/en-us/library/dd723678%28WS.10%29.aspx

Re:Apps hard to secure... (0)

Anonymous Coward | more than 2 years ago | (#39165599)

> Windows has capabilities, the are called policies.

Something tells me that you have no knowledge what you are talking about.

Polices in Windows per your links is more akin to Apparmor than capsicum.

Please educate yourself before you spew misinformation.

Bullshit metrics (0)

Anonymous Coward | more than 2 years ago | (#39161545)

Hey look! I can do it in only one line of code using my unicornfarts() method! //Sandbox browser
unicornfarts(); //Whew! Look how awesome I am!

Nevermind everything else that is going on "under the hood" when you use some other library. The 100 lines of code is a bullshit metric.

Re:Bullshit metrics (1)

F.Ultra (1673484) | more than 2 years ago | (#39161653)

No it's not a bullshit metric. Minimizing the amount of work the applications has to do in order to use the feature means less code that those applications coders can fuck up while the larger number of lines of code that is "under the hood" is shared so more work can be put into it in order to make it secure.

So we'll start measuring security (1)

Anonymous Coward | more than 2 years ago | (#39161577)

...in Scoville Units ? http://en.wikipedia.org/wiki/Scoville_scale [wikipedia.org]

Re:So we'll start measuring security (1)

PatPending (953482) | more than 2 years ago | (#39161679)

So we'll start measuring security in Scoville Units

And we will colloquially refer to the various levels as "Baby," "Posh," "Ginger," "Sporty," (and my personal favorite) "Scary".

Tear down the paywall (4, Informative)

Anonymous Coward | more than 2 years ago | (#39161631)

Here you go:

The Benets of Capability-based Protection
http://i.minus.com/1330308329/L4NpiCEFGVpDC5cIaD-oaA/dIgD7OB2SWXbD.pdf

A Taste of Capsicum: Practical Capabilities for UNIX
http://i.minus.com/1330308331/bOoWdETijD2_Eye5VsAKPQ/dvW7Ri9ZpoDDi.pdf

-- Not Aaron Swartz

Capsicum mostly dead (1)

Anonymous Coward | more than 2 years ago | (#39161753)

As far as I know, Capsicum has mostly run its course and been superseded by other umbrellas, particularly CTSRD. The page for the latter [cam.ac.uk] even refers to the former as a 'success project'.

Re:Capsicum mostly dead (1)

philip.paradis (2580427) | more than 2 years ago | (#39162511)

success project

Obligatory [diylol.com]

Sucess != Success (1)

Zero__Kelvin (151819) | more than 2 years ago | (#39163563)

Success Kid EPIC FAIL !

Re:Capsicum mostly dead (1)

TheRaven64 (641858) | more than 2 years ago | (#39163197)

Not really. CTSRD (pronounced 'custard') is a related project. It involves a custom MIPS-based chip and will be using capsicum as a benchmark. The aim is to see how systems like capsicum could be improved by adding some hardware support. Capsicum itself is largely finished as a research project, but that doesn't mean it's dead, quite the reverse. It's now shipped in the standard FreeBSD 9 install and it's being used outside the lab. There is still some Capsicum-related research going on, but this is largely related to libcapsicum and automatic refactoring of applications to take advantage of capabilities-based sandboxes (e.g. static and dynamic analysis to introduce privsep).

On the right track (1)

Okian Warrior (537106) | more than 2 years ago | (#39161851)

It seems to me that a capability model is the right solution.

Current OS access methods are woefully primitive and difficult to manage. To take two examples:

1) If you can write a file, you can make an executable

On windows, notepad can save a file as foo.exe, and you have an executable. On linux it's different but just as simple.

Very few programs actually need the capability to generate executables (the compiler, and the application installer, for instance). Allowing any and all programs to make executables along with regular file access means that any executable can be compromised into dropping malware onto your system.

Consider, for example, malware being sent around in pdf files or possibly image (ie - jpg) files.

A better model grants "can write executables" as a capability that is granted only to the programs that actually need it.

2) If an application can write a file, it can write a file anywhere any *other* application can write a file.

On windows and linux, file access is inherited from the user. This means, for example, that a program run by an administrator can write files virtually anywhere. To install an application means that you must trust the installation program because it can put anything anywhere.

A capability model could restrict a program to its install directory (c:\Program files\) and forbid access to system directories. This would prevent malware from being installed alongside good programs, and removing malware would be much easier (just delete the application install directory).

It sounds like we've finally come up with modern security models. This should make everyone safer, and perhaps completely eliminate malware.

Re:On the right track (2)

khb (266593) | more than 2 years ago | (#39162017)

Finally? Multics and others had such features before the birth on Unix.
Ecclesiastes 1:10 Is there anything of which one can say, "Look! This is something new"? It was here already, long ago; it was here before our time.

I prefer the original Hebrew

Re:On the right track (2)

Gaygirlie (1657131) | more than 2 years ago | (#39162295)

On windows, notepad can save a file as foo.exe, and you have an executable.

That's a rather bad example. Go ahead, open some executable file in notepad and save it, then try to run it, what do you get? Yes, that's right, it's totally corrupt. I do actually get your point, but notepad cannot do what you claim.

Very few programs actually need the capability to generate executables (the compiler, and the application installer, for instance). Allowing any and all programs to make executables along with regular file access means that any executable can be compromised into dropping malware onto your system.

How would the system know what the application is writing to a file unless it first allows the application to write to said file? Executables are not some sort of magic thingies, they're just binary data, and if you allow an application to write binary data then you are also allowing that application to write out executable code. There is no way for the operating system to know every possible type of binary file and that's that, what you suggest isn't possible. If you only mean that applications shouldn't be allowed to name their files "*.exe" then yes, that would certainly be possible, but that wouldn't solve the problem. Especially on non-Windows platforms where filename doesn't determine whether or not a file is executable.

This means, for example, that a program run by an administrator can write files virtually anywhere.

Well, indeed, that is the whole reason why administrator accounts exist: they're there so that administrators can do whatever they want!

To install an application means that you must trust the installation program because it can put anything anywhere.

A capability model could restrict a program to its install directory (c:\Program files\) and forbid access to system directories. This would prevent malware from being installed alongside good programs, and removing malware would be much easier (just delete the application install directory).

The real issue isn't where malware can install itself in, the real issue is what files it can read; OS can always be reinstalled should things go totally haywire, but user's personal files cannot. And yes, granular access control -- both reads and writes, like e.g. applications shouldn't just be able to even get a directory listing on the user's files unless the user specifically allows for that -- should be an integral part of any modern OS, too bad it isn't. It isn't a new idea, though, I've seen such mentioned already a decade ago and I'm sure such an idea has existed even longer, I just haven't been aware of it.

It sounds like we've finally come up with modern security models. This should make everyone safer, and perhaps completely eliminate malware.

Not even by a long shot.

Re:On the right track (1)

aaron552 (1621603) | more than 2 years ago | (#39163117)

If you only mean that applications shouldn't be allowed to name their files "*.exe" then yes, that would certainly be possible, but that wouldn't solve the problem. Especially on non-Windows platforms where filename doesn't determine whether or not a file is executable.

So you control which applications can set the "executable" flag.

e.g. applications shouldn't just be able to even get a directory listing on the user's files unless the user specifically allows for that

The problem is that this means any app that wants to access any data needs to ask for permission to do so. I don't see how prompting users for permission for every app that wants permission will help. I expect most apps to require at least the ability to read and write their own files to a location the users has access to from other apps, and properly managing which files/directories which apps can access seems to me like it would become incredibly convoluted and difficult to manage (from the user's perspective) incredibly quickly. Not that it couldn't be done, it would just be hard to make it usable and not a nuisance.

Re:On the right track (1)

Gaygirlie (1657131) | more than 2 years ago | (#39164139)

The problem is that this means any app that wants to access any data needs to ask for permission to do so. I don't see how prompting users for permission for every app that wants permission will help.

Opening standard operating system - provided File Open/Save dialog is in most cases more than enough; the application wouldn't be told the actual path to the file or allowed to get directory listing, but would be able to read and write the file selected in the dialog. There are exceptions, yes, but again that is nothing that couldn't be solved.

Re:On the right track (1)

TheRaven64 (641858) | more than 2 years ago | (#39164441)

The problem is that this means any app that wants to access any data needs to ask for permission to do so. I don't see how prompting users for permission for every app that wants permission will help.

There are basically three things that most apps need to access. Shared libraries, a scratch location, and user documents. Shared libraries are stored in the binary and rtld can grant access to them. A scratch location is easy - every application can be granted access to /tmp/{app name} or similar. User documents are easy to pass in from another process. You invoke the standard file chooser and it runs in an external process and gives you a file descriptor for the selected location.

The important thing with security is not having a solution that is applicable for every application, but having one that is simple and works in most cases. This means that people will actually enable it by default...

Re:On the right track (1)

hvdh (1447205) | more than 2 years ago | (#39163253)

On windows, notepad can save a file as foo.exe, and you have an executable.

That's a rather bad example. Go ahead, open some executable file in notepad and save it, then try to run it, what do you get? Yes, that's right, it's totally corrupt. I do actually get your point, but notepad cannot do what you claim.

Actually, there is some trick which allows to convert arbitrary machine code (.com, not .exe) to plain readable ASCII text.
Even changes in whitespace or line breaks will not hinder proper execution.

groups.google.com/group/comp.lang.asm.x86/browse_thread/thread/26a8ff035a6d81e0/e05e157df731963b?lnk=gst

Re:On the right track (0)

Anonymous Coward | more than 2 years ago | (#39167095)

The real issue isn't where malware can install itself in, the real issue is what files it can read; OS can always be reinstalled should things go totally haywire, but user's personal files cannot. And yes, granular access control -- both reads and writes, like e.g. applications shouldn't just be able to even get a directory listing on the user's files unless the user specifically allows for that -- should be an integral part of any modern OS, too bad it isn't. It isn't a new idea, though, I've seen such mentioned already a decade ago and I'm sure such an idea has existed even longer, I just haven't been aware of it.

Even that you have points, still your sayings does not make the point.

As the operating system is just a very small (but complex) program (or group of programs if it is Server-Client architecture) and it operates all hardware and all other running software.

Operating Systems like Linux (the Linux kernel) or FreeBSD (the FreeBSD kernel) are both monolithic operating systems. But NT operating system in Windows is Server-Client.
Yes, you can always re-install OS, as it just takes few seconds to do so. You see, Linux kernel what is monolithic operating system, exist in /boot/ and to re-install it, you only need to re-write Linux and then tweak GRUB (or other OS bootloader) if changing OS version and other settings.

Many Linux distributions did decades ago what you say, that they restricted from themselfs the user home directory except the config files. And many even made that user couldn't see outside of his/her ~.

But today distributors does not do that. Why? Well I don't know, as there are some problems in Linux chrooting.

OS is almost always the last defense line what is holding. And there are only specific malware targeted an operating system, those are rootkits (usually they are trojan horses as well). All other malware, worms, viruses, spyware etc does not even touch operating systems, but they attack against system programs and libraries or even application programs and its libraries.

Operating System already does protect process from others, but it can not protect process from its own stupidity. Like if process is going to do something what is permitted by OS, but wrong way by program designs, it is well accepted.

And here stands the SELinux version of Linux operating system. It blocks all functions what are not permitted. So you can example give rights to specific office application to have write and read access to ~/Documents/projectX/*.odt but does not have a clue that there are .odp files or any other. And then SELinux just allows that specific application to write those specific files. And those specific files to be opened and written only by process of that application.

So you can even protect a file from being red or written by any other process than wanted.

Re:On the right track (1)

philip.paradis (2580427) | more than 2 years ago | (#39162515)

On windows, notepad can save a file as foo.exe, and you have an executable.

No, you don't. Try to run that.

make imaginary.friends (-1, Offtopic)

ikmujn1 (2458940) | more than 2 years ago | (#39161949)

You welcome here to enjoy online http://www.care2.com/c2c/groups/disc.html?gpp=3802&pst=1375585 [care2.com] http://www.care2.com/c2c/groups/disc.html?gpp=3802&pst=1375603 [care2.com] http://www.care2.com/c2c/groups/disc.html?gpp=3802&pst=1375602 [care2.com] http://www.care2.com/c2c/groups/disc.html?gpp=3802&pst=1375601 [care2.com] http://www.care2.com/c2c/groups/disc.html?gpp=3802&pst=1375600 [care2.com] http://www.care2.com/c2c/groups/disc.html?gpp=3802&pst=1375599 [care2.com] http://www.care2.com/c2c/groups/disc.html?gpp=3802&pst=1375598 [care2.com] http://www.care2.com/c2c/groups/disc.html?gpp=3802&pst=1375597 [care2.com] http://www.care2.com/c2c/groups/disc.html?gpp=3802&pst=1375596 [care2.com] http://www.care2.com/c2c/groups/disc.html?gpp=3802&pst=1375595 [care2.com] http://www.care2.com/c2c/groups/disc.html?gpp=3802&pst=1375594 [care2.com] http://www.care2.com/c2c/groups/disc.html?gpp=3802&pst=1375593 [care2.com] http://www.care2.com/c2c/groups/disc.html?gpp=3802&pst=1375592 [care2.com] http://www.care2.com/c2c/groups/disc.html?gpp=3802&pst=1375591 [care2.com] http://www.care2.com/c2c/groups/disc.html?gpp=3802&pst=1375590 [care2.com] http://www.care2.com/c2c/groups/disc.html?gpp=3802&pst=1375589 [care2.com] http://www.care2.com/c2c/groups/disc.html?gpp=3802&pst=1375587 [care2.com] http://www.care2.com/c2c/groups/disc.html?gpp=3802&pst=1375586 [care2.com] http://www.care2.com/c2c/groups/disc.html?gpp=3802&pst=1375584 [care2.com] http://www.care2.com/c2c/groups/disc.html?gpp=3802&pst=1375582 [care2.com] http://www.care2.com/c2c/groups/disc.html?gpp=3802&pst=1375580 [care2.com] http://www.care2.com/c2c/groups/disc.html?gpp=3802&pst=1375579 [care2.com] http://www.care2.com/c2c/groups/disc.html?gpp=3802&pst=1375577 [care2.com] http://www.care2.com/c2c/groups/disc.html?gpp=3802&pst=1375576 [care2.com] http://www.care2.com/c2c/groups/disc.html?gpp=3802&pst=1375556 [care2.com] http://www.care2.com/c2c/groups/disc.html?gpp=3802&pst=1375557 [care2.com] http://www.care2.com/c2c/groups/disc.html?gpp=3802&pst=1375558 [care2.com] http://www.care2.com/c2c/groups/disc.html?gpp=3802&pst=1375560 [care2.com]

Linux OS in ChromeOS (1)

Fri13 (963421) | more than 2 years ago | (#39162505)

I wouldn't call ChromeOS as Thinclient OS as the same Linux operating system there is running as all popular Linux distributions and what is available for everyone from kernel.org.

Even that ChromeOS only offers to user a web browser (simplifying), it does not mean the operating system is for thinclients.

And even that web browser loads all "web apps" from network, it does not mean system is thinclient. Or otherwise I am typing this on thinclient what is really thin, as it is just 3.5cm thin and weights under 1Kg.

 

Thin, my ass. (0)

Anonymous Coward | more than 2 years ago | (#39162909)

Calling a browser "thin client" must be the worst euphemism in the computer bloatware industry in the last 30 years.

Capsicum video on YouTube (0)

Anonymous Coward | more than 2 years ago | (#39163041)

You can find a video of the original Capsicum talk at USENIX Security here:

    http://www.youtube.com/watch?v=raNx9L4VH2k

It talks about why Capsicum complements, rather than replaces, models such as SELinux and file system access control lists: existing tools solve some problems well (e.g., multi-user system security) but not others (e.g., web browser sandboxing), which is where Capsicum fits in.

Re:Capsicum video on YouTube (0)

Anonymous Coward | more than 2 years ago | (#39163085)

Better as an actual link: Capsicum talk at USENIX Security [youtube.com] that talks about how Capsicum complements existing security mechanisms in order to support better application security.

This is Slashdot! (0)

Anonymous Coward | more than 2 years ago | (#39164093)

What's going on? Linking to paywalled articles?

It's only 100 lines, so just blockquote the code and leave it at that.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>