headers
Christoph Badura | 5 Dec 2011 16:22
Picon
Favicon
Gravatar

Re: secmodel_register(9) API

On Tue, Nov 29, 2011 at 02:51:38AM +0100, Jean-Yves Migeon wrote:
> A few weeks back I tried adding a sysctl knob to allow users to control
> their CPU affinity. However, while implementing checks to restrict usage
> of this sysctl, I hit a limitation regarding secmodel(9): the current
> design cannot allow a secmodel to query the state/properties of other
> secmodels.

That is by design.  The idea behind splitting the decision process into
separate secmodels is to decouple the models and the decision making.

> So, when one wants to create sysctls that can only be changed when
> securelevel is below a certain level, you end up adding more hooks to
> secmodel_securelevel(9)...

That is intentional.  Every time a new control is added all the secmodels
need to be examined if they need updating.

> which is problematic, because the sysctl does
> not necessarily belong to this secmodel (consider curtain and suser, as
> an exemple).

Uh, sysctls do not "belong to a secmodel".  Whatever that is supposed to
mean.

> error = secmodel_eval("org.netbsd.secmodel.suser", "is-root",
>     cred, &isroot, NULL);

> This one asks the suser module if the user cred is assumed to be
> root when evaluated by suser module. If the module is present, it
> will respond. If absent, the call will return an error.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Jean-Yves Migeon | 5 Dec 2011 19:33
Picon
Favicon

Re: secmodel_register(9) API

(I am CC'ing Elad, as we both worked on it)

On Mon, 5 Dec 2011 16:22:33 +0100, Christoph Badura wrote:
> That is by design.  The idea behind splitting the decision process 
> into
> separate secmodels is to decouple the models and the decision making.

I can't see how -- secmodels are responsible for the decision making, 
so we cannot decouple these easily.

>> So, when one wants to create sysctls that can only be changed when
>> securelevel is below a certain level, you end up adding more hooks 
>> to
>> secmodel_securelevel(9)...
>
> That is intentional.  Every time a new control is added all the 
> secmodels
> need to be examined if they need updating.
>
>> which is problematic, because the sysctl does
>> not necessarily belong to this secmodel (consider curtain and suser, 
>> as
>> an exemple).
>
> Uh, sysctls do not "belong to a secmodel".  Whatever that is supposed 
> to
> mean.

Okay, let's put that differently: enabling/disabling a security feature 
like curtain has nothing to do with secmodel_suser(9) itself. Curtain is
(Continue reading)

Permalink | Reply | 6 comments |
headers
Elad Efrat | 5 Dec 2011 20:35
Picon

Re: secmodel_register(9) API

I don't understand what the problems are. In any case, this does not
violate anything. The language used to describe the supposed issues
with the new API is ridiculous.

What the new API allows is interaction between secmodels that are
built by people who are not part of NetBSD and don't want their
secmodel to become part of NetBSD but do want to take advantage of
features in secmodels provided by NetBSD.

Personally I don't care if this stays or not. All I can say is that I
have not seen a single argument worthy of consideration against it and
I would strongly recommend to leave it in.

Please don't CC me any further emails about this.

Elad

On Mon, Dec 5, 2011 at 1:33 PM, Jean-Yves Migeon
<jeanyves.migeon <at> free.fr> wrote:
> (I am CC'ing Elad, as we both worked on it)
>
> On Mon, 5 Dec 2011 16:22:33 +0100, Christoph Badura wrote:
>>
>> That is by design.  The idea behind splitting the decision process into
>> separate secmodels is to decouple the models and the decision making.
>
>
> I can't see how -- secmodels are responsible for the decision making, so we
> cannot decouple these easily.
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Aleksey Cheusov | 5 Dec 2011 21:15
Picon
Favicon

ASLR and PIE

Address Space Layout Randomization was implemented in NetBSD
years ago but all userspace utilities including daemons
are still built without PIC (Position Independend Code).

Was this made by intention?  If yes, can anybody please expain this
decision?

If no, can we build everything (or daemons) with PAE by default?

--

-- 
Best regards, Aleksey Cheusov.
Permalink | Reply | 2 comments |
headers
Thor Lancelot Simon | 5 Dec 2011 21:41
Picon
Favicon

Re: ASLR and PIE

On Mon, Dec 05, 2011 at 11:15:26PM +0300, Aleksey Cheusov wrote:
> Address Space Layout Randomization was implemented in NetBSD
> years ago but all userspace utilities including daemons
> are still built without PIC (Position Independend Code).
> 
> Was this made by intention?  If yes, can anybody please expain this
> decision?

On some platforms, ASLR in particular has a very large runtime cost
which is hard to avoid (it's not free anywhere).  Similarly, on
platforms which are register-poor, PIC is not always the best choice.

However, I have considerable experience with a NetBSD-based embedded
system which built as much as possible with PIE and ASLR.  This
revealed a number of issues which would, even if we decided to do so
immediately, make it impossible to build the whole system PIE and
run it with ASLR.  Among these are:

	1) Incompatibility of our thread library with ASLR.

	2) Incompatibility of crunchgen with object files built
	   for PIE, causing /rescue to be unbuildable.

	3) Incompatibility of our debugger with PIE executables and
	   with ASLR.

	4) Existence of various "private" libraries in the system
	   which are built using our library build framework but
	   not installed, thus making it hard to be sure you've
	   caught all the libraries and made them build PIC.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joerg Sonnenberger | 5 Dec 2011 22:13
Picon

Re: ASLR and PIE

On Mon, Dec 05, 2011 at 03:41:35PM -0500, Thor Lancelot Simon wrote:
> 	1) Incompatibility of our thread library with ASLR.

Except VAX, this is no longer a problem.

Joerg
Permalink | Reply | 0 comments |
headers
Alan Barrett | 5 Dec 2011 22:26
Gravatar

Re: secmodel_register(9) API

On Mon, 05 Dec 2011, Elad Efrat wrote:
> Personally I don't care if this stays or not. All I can say is 
> that I have not seen a single argument worthy of consideration 
> against it and I would strongly recommend to leave it in.

When you want to introduce a new feature, you should provide 
arguments in favour of the new feature, not merely say "there are 
no good arguments against it".  This is especially important in 
the case of features that have non-trivial security impact.

--apb (Alan Barrett)
Permalink | Reply | 0 comments |
headers
Christoph Badura | 6 Dec 2011 01:27
Picon
Favicon
Gravatar

Re: secmodel_register(9) API

On Mon, Dec 05, 2011 at 07:33:35PM +0100, Jean-Yves Migeon wrote:
> On Mon, 5 Dec 2011 16:22:33 +0100, Christoph Badura wrote:
> >That is by design.  The idea behind splitting the decision process
> >into
> >separate secmodels is to decouple the models and the decision making.
> I can't see how -- secmodels are responsible for the decision
> making, so we cannot decouple these easily.

secmodel_suser doesn't know about securelevel.  secmodel_securelevel
doesn't know about root.  Complete decoupling between models.

> Okay, let's put that differently: enabling/disabling a security
> feature like curtain has nothing to do with secmodel_suser(9)
> itself. Curtain is a feature that says: "only owners of an object
> can query information about it." So securelevel, suser, or bsd44...
> do not intervene in this process, _except_ when you are root
> (pragmatism always add exceptions). That's it.

That ("_except_ when you are root") works only by strongly coupling
curtain with secmodel_suser.  The coupling is actually so strong that you
cannot bring yourself to consider that asking "is-root" is not the only
possible approach.

OK.  Assuming that is the only possible way for the moment...
What you really want to do amounts to calling suser_isroot.  You could just
as well make that call directly and let the linker resolve the symbol.
That way you would satisfy the requirement that secmodel_suser is loaded
in a simple way. Instead you create a baroque interface that doesn't scale
and ends up doing the same thing just more complex and costly.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mouse | 9 Dec 2011 16:43

Re: Patch: new random pseudodevice

>> And note that at least one highly-thought-of modern design for an
>> entropy collector (Fortuna) doesn't even _try_ to keep an "entropy
>> estimate" -- the whole concept is pretty fuzzy when you start trying
>> to count how many bits you "took out".

> To extend on that: the basic idea is that as long as you started with
> "enough" entropy at some point and feed some form of entropy often
> enough, you have to break the cryptographic primitives pretty much
> completely to predict the output in any way.

Well, sure.  But that's equally true with no mixing at all: feed in
enough unknown ("random") information often enough and you don't have
to mix at all in order to get random information out.  Indeed, mixing
is a danger in that case, because it introduces the possibility of
correlation between past bits and future bits.

> One of the fundamental design assumptions behind Fortuna is that
> there is no correct way to estimate entropy.  People have been pretty
> bad about it whenever they tried.  So remove the need for it.

Unless you have a source of strongly random bits (eg, noise diode) of
higher bandwidth than the drain your consumers impose, there's no way
around it: you can estimate it badly or you can not estimate it at all.
Not estimating it at all amounts to estimating the amount of input
entropy as infinite, which is a worse estimate than almost any other.
"Because we can't do it well" is a really really bad reason to do it as
badly as possible.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mouse | 12 Dec 2011 08:30

Re: Patch: new random pseudodevice

> [...] I'm pretty sure the assertion you seem to keep making that if
> you use 128 bits of information to key a CSPRNG, or a cryptographic
> hash, or pretty much any other cryptographic device, then taking 128
> bits of output from the device is fine but the 129th bit is somehow
> suspect,

I don't think that's quite what I've been saying.

I've been saying that the output contains at most 128 bits of
information, no matter how many bits it's spread among.  This
information is not necessarily all present in the first 128 bits of
output, and, as you point out, if it is then it is a weakness in the CS
part of the PRNG.

> The argument that the 128 bits are indistinguishable from random
> instead relies on a computational expense argument:

Right.  That's why I consider it a weak argument - attacks just get
better.  Once upon a time, a Vigenère cipher was computationally
secure, in that nobody knew how to break it.

> knowing that codes are missing does an attacker no good unless he
> knows which codes are missing, and if the only way to determine which
> codes are missing is by trying all 2^N possible inputs to see what is
> *not* missing then, for sufficiently large N, the computation may be
> infeasible.

I see no reason to believe the first part.  Cryptography is littered
with cases where something general was known to be true but specifics
were unknown and it was used as a point of attack nevertheless.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane