Slashdot Mirror

That's exactly what CapDesk was designed to do: http://www.combex.com/tech/edesk.html

Even the OS eventually terminates. I'd still put forth my paradigm works.

An OS, as mathematical function, is a recursive, non-terminating program. It MAY terminate, but it need not.

Accounting is a part of management. However, management goes further in that it assumes responsibility for allocating and de-allocating resources.

Accounting is not done in any mainstream language in any usable manner. Regardless, I've been arguing the lifecycle of objects is better managed automatically than manually, and you have been arguing that, at least sometimes but likely often, lifecycle needs to be managed manually. The majority of security bugs found today would have been avoided if the software had been written in a memory-safe language, and many memory leaks would not exist given AMM. We can argue the performance tradeoffs of memory safety and AMM (empirical evidence suggest exec overheads around 15-20% and memory overheads around 50-100%), but that they both eliminate large classes of bugs, including security vulnerabilities, is an indisputable fact.

However, the programmer still should have a way to tell it when it is done - perhaps as the programmer I want to release memory half way through a function instead of waiting for the pointer to go out of scope when the function exits.

But why? If the region-inferencer (for example), determines that the lifecycle of a chunk of memory isn't used halfway through the function, then it will do it for you. If it's not smart enough, then you can refactor your function into two functions to ensure that regions are scoped differently. As a bonus, this results in a better design.

Further, your approach can have a pathological effect on performance due to micromanagement. Why incur all the overhead of alloc/free'ing individual objects when you can alloc/free entire regions of objects at once. This is incredibly efficient, and further, leads to more efficient bump-pointer allocation techniques. Are you aware of the searching and fragmentation overhead induced by libc's malloc/free? This has been extensively studied.

We know how to write software that is only as secure as the attack vectors that we are aware of. Claiming otherwise is foolishness.

I can legitimately claim otherwise because software written to a POLA standard is maximally defensive, and so any remaining security holes are either
a) an implementation bug which does not follow the specification, or
b) inherent to the problem being solved and thus, fundamentally unsolvable without changing the problem specification.

Stronger static types systems help reduce a) (and C/C++ have very weak type systems), and b) is essentially unsolvable without manual intervention.

We can mitigate how software is affected by unknown attack vectors through Defensive Programming methodology, but even that can only truly protect against known vectors.

Like most generalities, your statement is both true and false. It is false in the sense that a POLA design is already maximally defensive, and so the security properties can't be made any stronger without changing the entire specification.

It's true because of the human factor in any system, and what you'll quickly find is that the majority of the security research by the capability security community are human-computer interaction attacks, ie. phishing, spoofing, etc. This is because automated attack vectors are no longer viable in POLA systems. I suggest you read the security audit of the DarpaBrowser built on the capability-secure language E for a taste.

The "Defensive Programming Methodology" is actually a degenerate, specialized case of capability security.

Additionally, reliance on a "memory-safe" language does not absolve you from buffer overflow attacks. Such reliance is foolishness - and is no better than security through obscur

It's the sandboxing. A program run by a given user doesn't automatically get the user's full permissions -- it only gets a small subset. For example, it can't open files from the user's home directory other than by calling a trusted system File Open dialog, which allows the user to select the file and returns an open file handle to the application (or in OLPC's case hardlinks the file into the chroot jail).

In terms of research projects, see the secure scripting language E and the proof of concept CapDesk.

Interestingly, in the commercial world it only seems to turn up in safe bytecode runtimes -- there's very little out there for native code. For an example of something similar in concept look at JNLP or ClickOnce deployers.

See my #17367208 above

In that comment you are fixated on gaining root. The point is, you don't need root to do damage to everything you care about. For example, malicious code running as the user can turn the machine into a spam box. Want to steal online banking? No problem, replace whatever shortcut launches the browser with a wrapper that looks for banking transactions. Got any sensitive files? Those are up for grabs. Root is not needed.

The link is for a presentation about Windows.

Where did you draw that conclusion from? Everything in the talk applies equally well to Linux. Regarding not wanting to watch a video, I will say that the first 10 minutes illustrates the huge security flaws that both Windows and Linux suffer from. The rest of the video focuses on a better security model.

I'm not unsympathetic, I prefer a nice HTML writeup too. There's a page on CapDesk that has the basic ideas.

You seem to be down on Linux, up on Windows.

Nope, I never said Windows had better security. I'm a Linux user, but I know that the "Linux is secure" mantra is a myth. If every Windows user switched to Ubuntu, we'd still have the same security situation all over again. Root is hardly any security at all when you trust every application you run with all your data and privileges.

1. Capability Myths Demolished
2. Darpa security review of CapDesk
3. SCOLL: A Language for Safe, Capability-based Collaboration
4. SCOLL and SCOLLAR : Safe Collaboration based on Partial Trust

That said, I haven't seen a really good way to manage permissions. It's just not practical for an applet to say, "In order to run this, you need these 47 permissions" and expect you to fix that. With cleverness the modeler could create roles with aggregates of permissions, so that you can say, "This app needs access to your browser UI" (like Tabbrowser).

I find it interesting that every application has to wrestle with these problems time and time again, instead of them being solved by the operating system. The reason for all this trouble is that the Access Control List security model is inherently flawed.

Using ACLs makes us adjust permissions per user basis, while it is not the user who does (good or evil) things with the computer but the processes running on behalf of the user. Thus an application can (be tricked to) do malicious things with the user's full permissions - as if the user himself was actively and knowingly destroying his data, sending it over to an eavesdropper, etc. A correct approach would be to grant permissions to do a certain operation on a certain resource per process basis. This is what the capability based security is all about. (If I am mistaken, I hope someone more enlightened in CAP theory will correct me).

I am amazed that none of the popular operating systems implement capability based security models, since they would eliminate Confused Deputy Problems like this.

Some random links relating to Capability based security:

• A cool tech demo of what capability based security would mean in a desktop setting
• Granma's Rules of POLA
• Split Capabilities for Access Control - an interesting implementation from HP
• A discussion of ACLs and their problems, with links to CAP related pages