Fwd: QtO3D, from O3D-discuss

_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk

Re: Reducing Ambient user authority in a Type Safe /Memory Safe OS.

On Thu, December 31, 2009 01:09, Marcus Brinkmann wrote:
> Rob Meijer wrote:
>> On Fri, December 18, 2009 13:58, Marcus Brinkmann wrote:
>>> Rob Meijer wrote:
>>>> The process of creating an anonymous file to my knowledge still uses
>>>> linking into a namespace that is vulnerable to race condition attacks.
>>> It's only vulnerable if used incorrectly ever since O_EXCL was added,
>>> see
>>> mkstemp(3).
>>
>> The O_EXCL flag only makes sure that a named file does not already exist
>> within the given namespace before creating it. The problem remains that
>> in
>> between the open with O_CREAT | O_EXCL, or mkstemp for that matter, and
>> the moment of unlink, we have a short moment that the file exists in the
>> global namespace, and a hostile process could potentially gain access to
>> it.
>
> As (among other reasons) all file descriptors are linked into
> /proc/PID/fd/NR
> with the same access restrictions as a file created by mkstemp(), I can
> not
> see a significant difference.  Maybe you can explain it to me.

Your right, access to /proc/$PID (where /proc/$PID is not equal to
/proc/self) in effect renders all ideas you might have about implementing
fine grained access control on *NIX effectively useless.
With MinorFs this has been a major problem up to now, as MAC systems
AppArmor that MinorFs depends on, untill this day does not allow to
express the difference between /proc/$somepid and /proc/$mypid. This is
however something that as I understand is on the feature list for the
upcoming
major release of AppArmor. I feel this distinction is essential for
allowing to do any kind of least authority retrofit system on *NIX.

If we assume however that it is quite possible for many programs to run
perfectly without any implicit access to /proc/$mypid, and thus can
restrict quit a lot of programs so that they don't have access to this,
than it remains useful if we could be able to create unnamed files without
using a shared namespace.

Re: Reducing Ambient user authority in a Type Safe /Memory Safe OS.

Rob Meijer wrote:
> On Thu, December 31, 2009 01:09, Marcus Brinkmann wrote:
> If we assume however that it is quite possible for many programs to run
> perfectly without any implicit access to /proc/$mypid, and thus can
> restrict quit a lot of programs so that they don't have access to this,
> than it remains useful if we could be able to create unnamed files without
> using a shared namespace.

If programs in general don't have access to /proc (but some programs do) then
you are giving up on the concept of a globally shared namespace, and you can
just go all the way and give each process its own /tmp directory.  You
mentioned that this is already done by MinorFS.

The utility of anonymous files seems dubious, as it makes it hard to account
for resource usage properly.  This seems to be rather a misfeature of Unix.
You are probably better off using named files or, depending on usage,
anonymous (or shared) memory+fopencookie/funopen.  An important class of use
cases for dir_mkfile in the Hurd are atomic operations (files created with
content).  For this, the traditional tmpfile+rename based approach is
certainly usable, and a more ambitious solution would be a transaction-based
filesystem interface.  Nothing of this is directly related to security issues,
though (if implemented correctly).

Thanks,
Marcus

Re: Reducing Ambient user authority in a Type Safe /Memory Safe OS.

Marcus Brinkmann wrote:
> Rob Meijer wrote:
>> On Thu, December 31, 2009 01:09, Marcus Brinkmann wrote:
>> If we assume however that it is quite possible for many programs to run
>> perfectly without any implicit access to /proc/$mypid, and thus can
>> restrict quit a lot of programs so that they don't have access to this,
>> than it remains useful if we could be able to create unnamed files without
>> using a shared namespace.
> 
> If programs in general don't have access to /proc (but some programs do) then
> you are giving up on the concept of a globally shared namespace, and you can
> just go all the way and give each process its own /tmp directory.  You
> mentioned that this is already done by MinorFS.
> 
> The utility of anonymous files seems dubious, as it makes it hard to account
> for resource usage properly.  This seems to be rather a misfeature of Unix.

Not really. You need a way to account for resources (including memory
segments) held by processes and not linked into the filesystem, anyway.
So files held open by a process can just be accounted to that process.
Files linked from multiple places should be accounted to all of those
places (each for the full size).

--

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk

Re: Reducing Ambient user authority in a Type Safe /Memory Safe OS.

david-sarah@... (David-Sarah Hopwood) on Saturday, January
2, 2010 wrote:

>Not really. You need a way to account for resources (including memory
>segments) held by processes and not linked into the filesystem, anyway.

Agreed.

>So files held open by a process can just be accounted to that process.
>Files linked from multiple places should be accounted to all of those
>places (each for the full size).

How you account for shared resources is a religious issue, and I'm an
agnostic.

IMHO, it is good to allow many users to share the cost of an expensive
resource, possibly making something that would otherwise be too expensive
for one affordable for all.

OTOH, I've been in the computer services business, now called "cloud
computing". If you can get every user to pay full price for a shared
resource, you make more money.

The only good news in this well-trodden area is that storage continues to
get cheaper, so how you charge for it matters less for old uses.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | gets() remains as a monument | Periwinkle
(408)356-8506      | to C's continuing support of | 16345 Englewood Ave
www.pwpconsult.com | buffer overruns.             | Los Gatos, CA 95032

Re: Reducing Ambient user authority in a Type Safe /Memory Safe OS.

_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk

Re: Reducing Ambient user authority in a Type Safe/Memory Safe OS.

Bill Frantz wrote:
> david-sarah@... (David-Sarah Hopwood) on Saturday, January
2, 2010 wrote:
> 
>> Not really. You need a way to account for resources (including memory
>> segments) held by processes and not linked into the filesystem, anyway.
> 
> Agreed.
> 
>> So files held open by a process can just be accounted to that process.
>> Files linked from multiple places should be accounted to all of those
>> places (each for the full size).
> 
> How you account for shared resources is a religious issue, and I'm an
> agnostic.
> 
> IMHO, it is good to allow many users to share the cost of an expensive
> resource, possibly making something that would otherwise be too expensive
> for one affordable for all.

It is indeed a religious issue, but my particular sect does have some
concrete rationale:

If a subject has a strong reference to an object, then it's causing the
object to be retained. If it were not charged the full price, then
other subjects' actions could cause the price it is paying to increase
unexpectedly.

If a subject has a weak reference to an object, then it's not causing the
object to be retained, and therefore needn't be charged. Of course this
requires the subject to handle errors if the reference breaks.

Given this policy, it's possible to implement cost-sharing references as
a higher-level abstraction: a trusted broker holds a strong reference to
an object, then charges for the weak references that it gives out. The
broker's contracts with its clients can specify conditions under which it
guarantees that the weak references will not break, for as long as the
broker remains in existence.

--

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk

nice article about usefulness of "security advice"

<OT>
I wish everybody here all the best in this year 2010 (health, love,
happiness, success and not excluding $$$)
</OT>

Despite the origin (One Microsoft Way) of this article:

http://research.microsoft.com/en-us/um/people/cormac/papers/2009/SoLongAndNoThanks.pdf

The part I like is:

it openly points to the prevalent effort to pretend security effort by
giving various vague promises concerning "improving security". I like
the following sincere observation:

<CITE>
Given a choice between dancing pigs and security,
users will pick dancing pigs every time." While amus-
ing, this is unfair: users are never offered security, either
on its own or as an alternative to anything else. They
are offered long, complex and growing sets of advice,
mandates, policy updates and tips. These sometimes
carry vague and tentative suggestions of reduced risk,
never security. We have shown that much of this advice
does nothing to make users more secure, and some of it
is harmful in its own right. Security is not something
users are offered and turn down. What they are offered
and do turn down is crushingly complex security advice
that promises little and delivers less.
</CITE>

Promoters of mainstream security tools would probably refute it.

Re: nice article about usefulness of "security advice"

There's a reference to Ptolemy epicycles on page 2 as well.

--

-- 
  Dominique Quatravaux
  +41 79 609 40 72

Re: nice article about usefulness of "security advice"

Dominique Quatravaux wrote:
> There's a reference to Ptolemy epicycles on page 2 as well.

That is also a good analogy.

One way how to fight nonsense is to show its funny part, to have fun of
it  and enable others to have fun of it. Nonsense should not appear
serious. This man is on the right track  I wish everybody a lot of fun.