At 9:21 PM on Sep 16, 2007, Peter Gutmann wrote:
I recently ran across something
that looks like a commercial CapDesk-like
system, a bit like Polaris but it's an actual shipping commercial
Unfortunately the info on their web site,
http://www.gentlesecurity.com/technology.html, is a rather fuzzy, and
detailed review I've seen of it is in German (this month's iX
I looked a bit through what I could find on-line for iX magazine, I
but was unable to find the detailed review that Peter refers to.
Perhaps somebody (Peter?) could supply the URL? My German is
weak, so I'm not confident I'd be able to get a detailed
from the article, but I have a number of German colleagues who I
be able to ask to review the description so that we could discuss
it, if that seems worthwhile.
At 03:20 AM 9/17/2007, Mark Miller wrote:
pgut001-kVWAYfnMFF2W8ldZTk/re6VXKuFTiq87@public.gmane.org <pgut001-kVWAYfnMFF2W8ldZTk/re6VXKuFTiq87@public.gmane.org> wrote:
> I recently ran across something that looks like a commercial
>From a brief glance, I notice that the diagram they use at
http://www.gentlesecurity.com/pix/005_1.png> is an almost
transpose of the diagram we've been using to explain the benefits of
the CapDesk-like approach, though
http://www.gentlesecurity.com/comparison.html> makes no mention
CapDesk, Polaris, Plash, or Bitfrost.
Hmmm. That "comparison" is awfully generic. The
description of their "access control policy" on:
The GeSWall access control policy determines how GeSWall will restrict
access by applications to system resources. Resources are files, registry
keys, processes etc. and all resources are categorized as either
untrusted, trusted or confidential.
The access restriction policy is composed of both generic rules which
apply to all applications and specific rules which apply to only one
The generic rules for an isolated application are that the application:
- Can read but cannot modify trusted resources.
- Cannot read or modify confidential resources.
- May create new untrusted resources, e.g. files.
- May read or modify untrusted resources.
The only generic rule for a non-isolated application is that the
application cannot load untrusted executables into its address space. All
other resources access are allowed.
These generic rules are overridden by any application specific rules in
the application database.
All resources are trusted except those created by isolated applications.
Resources created by isolated applications are untrusted. Confidential
resources are any resources, which are marked as confidential in the
database. By default, any files in a user My
Documents\Confidential folder are confidential. You may specify
additional untrusted and confidential resources explicitly by their name
sounds quite unlike POLA/capabilities to me:
Firstly with regard to POLA: At least in so far as the discussion
focuses on the "generic" access control policy for 'isolated'
applications, it seems that they have an 'ambient' authority
Secondly, with regard to the dynamics of access control (e.g. the
permission as parameter mechanism that capabilities use): I don't
see anything that suggests how permissions are granted - namely added to
their "application database". However, the fact that it
is referred to as an "application database" suggests to me that
the changes are unlike parameter passing - i.e. unlike
When they discuss their demo on:
I have to admit that a description like:
Please note attacks are simulation of actions identical mal-ware ones. No
any info is really leaked or file deleted from your system. After every
attack probe, script performs cleanup by deleting created files and
Once script completed command prompt kept open, so you can review whole
output or re-start the script again.
doesn't inspire a lot of confidence. I'm reluctant to trust this
code on a Windows system that I need for anything else.
Has anybody else run the demo (e.g. with no apparent negative results
from an install, run, uninstall)?
Also, they use the "mandatory" term, e.g. from:
as, "The key feature of GeSWall is the unification of a mandatory
multi-level security policy with usability."
Naturally one wonders what they mean by 'mandatory' in that
context. That is, 'mandatory' from what viewpoint? I don't
want to dive into that discussion here, but it certainly suggests that at
least from the viewpoint of what they refer to as 'isolated
applications', such applications are unable to dynamically effect access
control. E.g. unable to communicate permissions as
'capabilities'. That to me sounds like something more along the
lines of an "SELinux" add on that would likely be so rigid
(from the viewpoint of running applications) and demand so much
privileged attention (whoever or whatever is able to change the
'application database') as to be effectively unusable beyond a few canned
Of course these thoughts are just from the rather limited information
I've been able to get from their Web site. I'd be interested to
hear more about how their "application database" is managed and
how it's access control restrictions are enforced.