Hello,

Outlined in this mail is my proposal for integrating the traditional BSD
securelevel with the kauth(9) interface.

This mail lightly uses some kauth(9) terminology; an online version of
the man-page is available from http://www.bsd.org.il/netbsd/kauth.9.html


It was discussed in the past ("The reason for securelevel") that we need
to separate the impact of securelevel to allow finer-grained control
over what can or cannot be done in our system. For example, an
administrator might like to customize the impact of the securelevel
combining several implications from securelevel 2 but otherwise all the
affects of securelevel 1.

On the other hand, some people may not want any of this. The solution
must allow people who would like to stick to the current model of
securelevel the ability to do so.

The proposal in this mail is divided in two. The first part will discuss
the proposed kernel backend to replace securelevel. The second part will
discuss possible (optional) userland enhancements that will allow the
finer-grained access mentioned above to people who need it.

The only issue with replacing the securelevel implementation is
third-party LKMs. This is because they may rely on the availability of a
"securelevel" variable. For example, a driver that according to the
securelevel allows or denies a certain request.

The magnitude of this issue needs to be realized: this affects only LKMs
that were written specifically for BSD systems, as a vanilla Linux (and
perhaps Solaris? I don't know) kernel does not provide a securelevel
mechanism.

The first part of this proposal will also describe possible solutions to
this problem.

1. Kernel backend

  At the moment, the kernel implementation of securelevel is very
  simple: a single (raise-only, sysctl-able) variable, "securelevel",
  that is checked in various parts of the kernel whenever a
  securelevel-relevant operation is requested. This means that the
  interface to securelevel is also its implementation.

  The s...
[ message continues ]

the fact that "access raw memory" and "change firewall rule" are
controlled by securelevel is not a good reason to put them into
a single scope, IMO.
it's better to write listeners to check "securelevel" variable
for appropriate scopes, rather than having a single scope gathering
these random operations.
ie. i think securelevel should be turned into listener(s), not a scope.


btw, it seems that you are proposing two different things in this mail.
	- adapt securelevel to kauth world
	- make securelevel a bitmap

i'm not sure if the latter is a good idea.
why bother to complicate securelevel, while you can just have
another listener to implement finer-grained access control?

YAMAMOTO Takashi

True. The reason I did put them into a single scope was that,
originally, I had intended for the "system" scope to be something
like Thor posted about -- collection of changes that might affect
the TCB.

We could, and perhaps even should, do this right by splitting it up
as you suggest.

When I first started some work on splitting up securelevel (before
I figured integrating it with kauth(9) would be the best thing to
do) I compiled a list of what securelevel really does. Most of the
list is divided to file-system related knobs (file flags and mounts),
kernel related knobs (LKMs, time adjustment, sysctl(9), corename),
raw memory access (/dev/mem and /dev/kmem), networking (packet filter
rules and net80211 modules), and process manipulation (via systrace,
ptrace, procfs -- or these also belong in kernel?). Also, there are
few securelevel impacts that are located in MD code that I haven't
yet checked out thoroughly.


IIUC, you mean to create several listeners that would each be in charge
of making a decision for different "knobs", and defer requests
otherwise?


It's not really "make securelevel a bitmap", but introduce a new
variable that'll store the information kauth(9) will refer to when a
request is made.

If now there's an "int securelevel" kernel code can check before
granting access to, say, open the raw memory device; if we are splitting
the knobs, we need a place to store the values for all these knobs.

Where else would information such as "modifications to the packet
filter rules are disallowed" will be kept? (granted, that's got to
do more with the security model used; let's assume "traditional Unix"
for the context ;)

...or am I not understanding you correctly?

-e.

-- 
Elad Efrat

i meant, eg. you can write an listener like the following and
register it to KAUTH_SCOPE_PROCESS scope, to replace securelevel checks
in sys_ptrace() and process_checkioperm().

	int
	securelevel_process_listener_callback(....)
	{
		switch () {
		case KAUTH_PROCESS_CANPTRACE:
		case KAUTH_PROCESS_CANIO:
			if (p == initproc && securelevel > -1) {
				return KAUTH_RESULT_DENY;
			}
		}
		return KAUTH_RESULT_DEFER;

see the above example.
"int securelevel" should be enough to implement securelevel as a listener.

for the case of "filter rule modification", you can write another listener for
the scope which covers the operation.
yes, you need to create an appropriate scope, i think.

YAMAMOTO Takashi

But you lose the ability to set custom knobs, as was already previously
discussed... (because you have only one securelevel variable, and not
where to store indication on which knobs are raised or not)

Another consideration is that the number of listeners can directly
affect the performance of an authorization request for a given scope.
That said, we might want to add the "KAUTH_PROCESS_CANIO", for example,
to the default listener for the process scope, instead of creating a new

Yes, a network scope.. and, as a side-note, I'm pretty sure we could use
kauth(9) to do what pfil(9) is doing now, but this is a rather critical
part that'll have to go under some serious performance tests if we ever
think in that direction. :)

-e.

-- 
Elad Efrat

sorry, i think i missed the previous discussion.
can you give me a pointer to it?  was it in this thread?

maybe.
because coalescing listeners is merely an optimization,

i'm pretty sure it's an abuse of the interface. :)

YAMAMOTO Takashi

Sure, my post on this is available at:

http://mail-index.netbsd.org/tech-security/2006/01/26/0004.html

(it basically suggested that if the admin is interested, he can choose
to have multiple knobs that each controls a different aspect of what

No problem. Do you have suggestions for what other scopes we might want
to introduce to cover the other aspects of securelevel?

-e.

-- 
Elad Efrat

thanks.
it sounds like an orthogonal topic to me.
you can always have a listener to check "costum knobs".
(or coalesce it with another listener, if it turns out that

- "lkm" scope?
- "vfs namespace" scope for mount/unmount/etc?
- "machdep" scope?
- "specfs" scope for kmem and raw device?
- "immutable bit" thing should be a part of FILEOP or VNODE scope, maybe.
- misc things might be a part of existing "generic" scope.

it might not be worth to have fine-grained scopes for
slow operations like lkm and mount.

i don't think it's necessary to hurry up to create
scopes for this purpose because there's no need to convert
all securelevel checks at once.
it might be better to create scopes necessary for things currently using
suser first, and see if each aspects of securelevel fit into them,
because the former is more primary user of kauth.
(or wait for apple defining scopes. :-)

YAMAMOTO Takashi

I'm not sure I follow. What would the listener check if there aren't

Some things that are worth saying here...

The vnode scope is used only for access control operations -- the
permission checks that are now part of the file-system code -- because
it's *very* heavily used. I suggest we trust Apple on this one and not
attempt to add more things to it.

As for the other scopes, you see what kind of mess is created here? we
introduce more scopes than actually necessary and over-complicate it.
I assume we'll end up placing knobs for the "lkm", "machdep", "specfs"
scopes and the misc. things in the generic scope. The fileop scope does
not seem right for things like handling the immutable (and other) bits,
so that'd probably go in generic as well.

The "machdep" scope is actually more of a i386/amd64/xen scope; don't
quote me on it but I think there is very minimal use -- if any -- of
securelevel in other MD code.

So... it might be the case that introducing a new scope that can be
called "system" (or, "TCB" :) to control the variety of knobs that might
affect the TCB be worthwhile, after all...

Of course, this is just my opinion, and I'd be more than happy if others

This I don't agree with. As my original post on the thread said, there
are going to be two ways for handling the securelevel implications: the
"traditional" way and the "new" (multi-knobbed) way. If we change only

That's an excellent suggestion. The amount of converted-suser() calls in
the kernel is rather large, so if other developers are interested in
helping to identify what privilege is requested in each of them we can
achieve that faster.

I wouldn't want to think, however, that we'll hold with the securelevel
work because of it. A large amount of the work is changing the
references to securelevel to kauth(9) calls with the proper request,
and for that we don't need to wait until all converted-suser() calls
have more descriptive requests, IMHO. :)

-e.

-- 
Elad Efrat

i don't think splitting securelevel is a good way to achieve

TN mentions KAUTH_VNODE_WRITE_SECURITY/KAUTH_VNODE_NOIMMUTABLE, which

yes, i agree it's a trade-off among some kind of cleaness, efficiency, etc.

	- performance critical scopes should be small as far as possible.
	- don't care much about others.

a possible concern; in future, we might introduce a performance critical
operation which semantically fits one of scopes which is not performance

i don't think "tcb" is a good idea because some aspects of securelevel
have more appropriate scopes.  and we already have "generic" scope for

i think one of the points of securelevel is being "a simple system
global knob".  if you want fine-grained control, it shouldn't be done by
splitting securelevel, IMO.  you can have both of securelevel listener and

anyway, we need to factor out a set of operations/scopes necessary for
suser and securelevel.  ie. non trivial work :)

maybe you can use ISSUSER-like temporary placeholder for some aspects of
securelevel which don't have approrpriate scopes for now.
i'm not sure if it's much better than direct manipulation of
securelevel variable, tho.

YAMAMOTO Takashi

But this is a discussion we *already had* and is not the subject of the
thread. What *you* think is irrelevant, because *you* are given the
choice to use whatever interface you want -- be it a single knob, or
multiple knobs.

We've been through that before. My initial post started with saying
something "as we agreed that some people *do* want it, here is how

The vnode scope is what Mac OS X uses to take the permission checks out
of each file-system specific code and into the VFS layer. We are not
implementing it just yet, so this is out of the question.

Since this is a single case, IF we do decide to implement what I
suggested, and WHEN we get around to have extended attributes working,
and IF we decide to have the vnode scope handle the permission/ACL
checks all in one place, and WHEN we get around to implementing that
too, I promise you that I'll take care of that bit. :)


Yes, but I'm not sure these are "misc. operations"..

I'll give you two examples of operations: the first, is checking if
process A can "look into" process B. We use this check for things like
filtering ps and netstat output per-user. The second operation is "can
this process attach systrace to init". Obviously, this is a process
related operation, because the very act of attaching systrace (or
ptrace, for that matter) belongs -- clearly -- in the process scope.

However, I was suggesting a different point of view: there *is* a
difference between these two operations, the difference that justified
the creation of securelevel. While the first operation can cause little
harm to the system (so what if joeblow gets to see root owned
processes?), the second operation suggests that joeblow (or a
compromised root) could attach to init, manipulating it, compromising
the TCB.

This could very easily start an endless discussion. There is no right
answer for this one, I'm afraid. On one hand, we can have the
securelevel-related operations scattered across several scopes, possibly
even handled by different list...
[ message continues ]

I've followed the kauth design process at Apple, and the NetBSD discussions 
along these topics with interest, having gone through much the same process in 
the integrating of mandatory access control and ACLs into FreeBSD a few years 
ago.  I thought I'd share a few thoughts, which you're welcome to ignore. :-)

The problem of categorizing checks is actually quite difficult -- in the 
TrustedBSD MAC Framework in FreeBSD, we end up avoiding the issue by not 
categorizing access control checks at all, but loosely naming them based on 
the "object" of the operation.  LSM takes a very similar approach.  The Darwin 
kauth framework has been influenced by the MAC Framework design, but takes a 
more explicit approach to categorization.  I've always liked the notion that 
we categorize operations, and checks more specifically, by the object type. 
This is made tricky when you have checks that involve multiple objects without 
an explicit subject, however.  For example, the check to deliver an mbuf to a 
socket in FreeBSD is a subject-free operation.  In the end, all this comes 
down to is the ease of grasp of the framework for the developer, and the ease 
with which they can express the policy they want to implement.  The 
object-oriented view of the world is useful, though, and thinking about it as 
objects and methods is a useful way to think about things.

kauth(9) is an interesting framework, and clearly benefits from a lot of the 
prior work, be it FLASK, LSM, the MAC Framework, etc.  It's a carefully 
selected subset intended to support Apple's critical audiences -- workstation 
firewall vendors, anti-virus vendors, the need to introduce ACLs, etc.  It 
doesn't meet the full set of needs we have in FreeBSD -- for example, it does 
not provide clear object life cycles and labeling facilities required for 
mandatory access control.  One of the design choices in kauth(9) is to provide 
relatively few methods for the security module to implement -- this is helpful 
in some ways, and mak...
[ message continues ]

I also suspect that the code paths get a lot shorter.
And probably easier to read...

If all the calls to a routine end up passing a constant parameter
telling the called function what to do (which I suspect ends up being
the case here), you save the cost of pushing the argument + the cost
of the switch statement (and can maybe even sensibly inline the code
itself)....

If, for instance, you run netbsd under bochs, you can get an instruction
trace output.  Executing simple system calls shows that a lot of the
time is spend faffing about in lockmgr.
We don't want to do the same for the authorization checks.

	David

-- 
David Laight: david@l8s.co.uk

This is true.  On the other hand, we ended up with a god-awful number of 
interfaces that each module needs to provide.  :-)  The LSM/MAC Framework 
model uses C99 sparse structure initialization to populate large structures of 
possibly defined function pointers with function pointers defined by the 
policy.  The older MAC Framework, FLASK, and now kauth(9) interface specifies 
a small number of entry functions but a large number of index value(s) 
specifying what event it is, which allows interpretation of the arguments.

Finding a middle ground between those two is tricky, since the C language 

I'm much happier with the newer FreeBSD kernel locking APIs for this very 
reason -- you can see them separately in trace and profile output, you can 
substitute definitions at the symbol level, you get strong type checking, etc. 
All that said, I recognize there is a lot of value to the indexed argument 
method -- you may lose type checking and the function behavior, but it greatly 
reduces the amount of C glue required for the registration process, and allows 
very simple policies to coalesce decision logic if they're able to 
consistently ignore arguments.  TrustedBSD MAC modules tend to be quite long 
with a lot of fairly empty functions that map the specific typed arguments 
into something the logic of the policy can operate on.  I.e.:

static int
mac_mls_check_vnode_read(struct ucred *active_cred, struct ucred *file_cred,
     struct vnode *vp, struct label *label)
{
         struct mac_mls *subj, *obj;

         if (!mac_mls_enabled || !revocation_enabled)
                 return (0);

         subj = SLOT(active_cred->cr_label);
         obj = SLOT(label);

         if (!mac_mls_dominate_effective(subj, obj))
                 return (EACCES);

         return (0);
}

Because the argument order and types of arguments vary, we can't easily 
combine functions implementing similar checks for different object types.

My currently leaning is that the MAC Framework slig...
[ message continues ]

=20
=20
Thankyou very much for your insightful and constructive
contributions. You bring perspective not only from practical
implementation and deployment, but also simply of the "bigger picture"
a suitable distance from the tangle of the immediate discussion.  This
wisdom is VERY welcome indeed.

I'm quite sure there's interest and value in commonality in these
frameworks; in addition to the pros and cons of each, the complexity
of the landscape weakens the chances of success for any of them.
=20
--=20
Dan.=20

sorry again, can you privide a pointer?
do you mean, has it already been decided to split securelevel into
multiple knobs?  even if so, it's orthogonal to kauth.
i understand there are people who want multiple knobs,


are you suggesting to leave it as securelevel variable check for now?



"it" here is "ISSUSER-like temporary placeholder" solution, right?

YAMAMOTO Takashi

Are you serious? you already asked once on this thread for a pointer to
an earlier discussion, and I gave it. If you read it, how are you asking
for a "pointer" again?

The thread that took place ~2 months ago, "The reason for securelevel",
discusses *exactly* that: letting you do what you want, and others do
what they want. Nor once did I suggest both on the previous and this
threads that this is to completely replace securelevel. It's merely

Do you want me to repeat myself again?

The current code NetBSD uses has suser() checks, euid checks,
and securelevel checks. I'm suggesting to get rid of that mess, and
implementing securelevel using a kauth(9) interface is one step in

Then how are you intending on having the separation of knobs if all you

If not everyone are happy, then I will simply not do what I suggest.

But I think you are wrong here too, because the discussion took itself
to places like code size and performance and further enhancing what we
have today by using run-levels, and was not tripped on "this is a bad
idea". So saying "not everyone seems happy" is ignoring the fact that,
at least as it seems to me, the *IDEA* of doing what I suggested was
accepted, but people are interested on what implications it will have

I will repeat myself once again, by saying that if we *do* do it, it
will be done right. Leaving a securelevel check beats the purpose. What

Hardly. The proposal is to integrate securelevel and kauth(9) as the
subject of this way-to-long thread suggests. The mail you are replying
to also implies, probably not clearly enough, that I am so tired of
these pointless arguments over tiny things that don't matter (this is
wa beyond bikeshed) that if you keep insisting on implementing these
knobs in their supposedly-appropriate scopes I'll just agree so we can,
for once, move forward.

I also asked that others comment on this issue as well so don't just

To keep on kauth(9) terminology, that is *not* "ISSUSER-like", but
rather kauth_authorize_foo() c...
[ message continues ]

i was not sure if you were referring to the same thread, so i asked.
i couldn't find any consensus about how to implement fine-grained control

i don't have any objection to implementing securelevel via kauth.

you can have listeners for fine-grained knobs, in addition to securelevel
listener.
because the former is not a securelevel anymore, it's reasonable to




i meant it's ISSUSER-like just in the sense that it's a temporary placeholder.


let me restate my opinions.

- handling securelevel via kauth is fine.

- in kauth world, securelevel should be implemented as listeners for
  appropriate scopes.

- if you want fine-grained control ("multiple knobs"),
  it should be another listener(s).  splitting securelevel is not a right way.
  (you might want to coalesce listeners to default one for performance.
  it's fine, but it doesn't change the logical structure, i think.)

- i'm not sure if securelevel is a good target to shoot now.
  it's better to tackle suser() first.

YAMAMOTO Takashi

That won't be necessary. Apparently, someone on this list (who contacted
me off list) find my "tone of voice" inappropriate. This is just, way,
way, way more than I can take. Sorry.

Proposal withdrawn.

-e.

-- 
Elad Efrat

"Don't let the bastards get you down."

I think what you are doing is important.  Kauth is a providing a framework
for implementing a policy but not the policy itself.  If someone wants
functionality like securelevel, they should implement a securelevel listener
that provides it.

So provide the framework, and let others provide the policy.
-- 
Matt Thomas                     email: matt@3am-software.com
3am Software Foundry              www: http://3am-software.com/bio/matt/
Cupertino, CA              disclaimer: I avow all knowledge of this message.

Don't let the 'opinion' of one individual turn your back on the rest of 

I hope you do not intend to stop working on this.

Cheers,
-- 
         Thomas E. Spanjaard
         tgen@netphreax.net

This sounds like a good aproach to me.

And yes, I do think that we want finer grained controll - at least remove
the obvious abuses of securelevel, as Thor pointed out, e.g. the packet filter
rule loading restrictions.

Martin

My understanding is that kauth will go into the kernel after 4.0 branches.=
=20
Probably just after.

Given that, I actually think it'd be fine to just go with option (b). The=
=20
problem I see with (a) is that it's easy to map a securelevel set request=
=20
(sysctl -w kern.securelevel=3Dfoo) to a bitmap, it's not so easy to do the=
=20
opposite. Since we don't know exactly what aspect of securelevel the LKM=20
is interested in, it's hard to say what securelevel a given LKM should=20
see.

So my suggestion is to make LKMs change. Include a quick description of=20
how to change them (the define you gave was good) and a mapping of what=20
you can find now (if you were interested in making sure ioctl's could=20
happen, you make this call. If you are interested in the ability to access=
=20
devices when others are busy, you make that call).

If this goes into 4.0, then I think you're right and we need both.

Take care,

Bill

Yes, this is certainly an issue I'm worried about as well... if we do go
the "reverse mapping" route, we should set the securelevel variable
depending on the knob bit in the mask belonging to the highest

I'll do that anyway, but the decision of requiring LKMs to change is not
one that I can make. :) I am just suggesting possible solutions that we
can use regardless of what we decide to do.

-e.

-- 
Elad Efrat

True, and I can't do it either. But voicing input can help make the=20
decision. :-)

Though if it all goes into 4.0, we will need the compat variable for at=20
least the 4.0 release.

Take care,

Bill

While I can see the benefit of having multiple bits, I don't see why
the 'securelevel' stuff ever needs to depend on curproc [1].

Neither can I see why you are suggesting this needs to be checked via
some listening service, and not be a simple bitmask check.
There is a suggestion that this might involve a double process switch....
I worry about the performance costs of this, and the fact that callers
may not be in a position where sleeping is valid.

	David

[1] splitting 'suser()' into multiple bits is a separate problem, made
worse by the necessity for 'suid' binaries and trusted path.
Not to say that it wouldn't be worthwhile.

-- 
David Laight: david@l8s.co.uk

It doesn't. The usage of curproc in the example was to illustrate that

The "listener" is kauth(9) terminology for a "callback", which is how
kauth(9) works: every scope has a list of callbacks that are called
whenever an authorization request on that scope. The actual check, as
I've shown, is done via a bitmask check.

One of the reasons I'm creating a scope and integrating securelevel
with kauth(9) is that this will allow us later to build more
sophisticated security models with little effort. One of the purposes
of using the kauth(9) framework is exactly that -- once it's well
integrated in the system, we can build on top of it anything we want,
easily allowing our users to choose between a traditional Unix security
model, capabilities, or MAC policies, because all authorization requests

I'll admit that I'm not sure where you see a possibility for a double
process switch to happen so before I can comment on it you'll have to

NetBSD is not the first OS to suggest changes as described above.

First, if using the traditional Unix security model, then all these bits
that were once suser() calls will, eventually, end up in a check for the
effective user-id.

As for the second issue -- the set-id mode bit will remain set, but will
have affect only in the traditional Unix security model. Otherwise, we
will have to store the required privileges (or "capabilities") of the
program in its extended attributes. This, however, is something that *I*
do not plan on implementing, which is why I haven't suggested yet any
design of a capabilities system.

Root retains its "powers" even with the suggested changes (either
kauth(9) or the ones to securelevel), but we have the framework to
easily take them away. :)

Hope this helps,

-e.

-- 
Elad Efrat

When I first read the proposal, I thought the "default listener" of the=20
original note was running in its own process context, thus you'd have to=20
context switch to it and then back again. I gather David read it the same=
=20
way.

A callback works much better. :-)

Take care,

Bill

Elad Efrat wrote:


Offer both of these solutions, and everyone should be happy. :-)  Even
better, item "a" should generate a warning message if possible.  (Maybe
if we ever get a true kernel loader, it could look for references to
securelevel and issue a warning.  Until we have a real kernel loader,
this might not be realistic.  :-)

We can announce eventual removal of securelevel as a variable at all,
but I think it makes sense to have a full release cycle in the middle to
allow folks with 3rd party code to adapt.

Btw, I would prefer not to have kauth be conditionally defined.  If
we're going to switch, we should just bite the bullet.    One question
that should probably be answered first would be to compare the size of a
kernel with kauth and without on some "size sensitive" machines: i386,
vax, and mips.  If the difference is minimal, then there is no point in
having a conditional, IMO.

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191

Yes, both "a" and "b" are planned to be done; sorry if it wasn't

Even though we can provide the wrapping to transparently hide the fact
that there are multiple knobs from users who don't care about it, I can
only assume some people will simply want to retain the traditional
behavior.

Either way, both of these decisions (generating a warning, removing the
kern.securelevel variable entirely) are ones that someone else will have

If kauth(9) will ever be integrated in NetBSD, it is not going to be
conditionally defined. The __HAVE_KERNELAUTH conditional was to
illustrate how a module that wants to support multiple versions of

Since you brought it up, there are two considerations we need to take
into account regarding kauth(9), the first being size (as you mentioned)
and the second being performance.

I have never compared the sizes of pre-kauth(9) and post-kauth(9)
kernels, but the changes that might affect the size are as follows:

  - Introduction of new code, the kauth(9) subsystem;
  - Removal of old code, mostly functions from kern/kern_prot.c;
  - Changing suser() calls to kauth_authorize_generic() calls;
  - Changing struct ucred/struct pcred accesses to kauth_cred_*()
    calls.

What would be a size difference that might make you worry? :)

As for performance, same list applies. There is a potential for slower
performance due to the way kauth(9) works: it dispatches authorization
requests to a list of listeners, making the amount of listeners directly
affect the performance of an authorization request.

My machines at home running kauth(9) have seen no performance impact at
all, but more testing on various architectures should be done to get
some "official" numbers...

-e.

-- 
Elad Efrat

On Fri, 24 Mar 2006 23:24:47 +0200

Was this profiled?  Of course, performance impact on the system as a
whole may become worse as more restrictions are applied to more types of
accesses as well, IMO. I.E. if more frequent code paths eventually also
need to verify for authorization (is this part of future goals?  What
are worst expected future scenarios?)

I would be interested in seeing common cases before/after profiled data,
considering the assumed overhead of a list of function pointers being
ran for a particular scope, with a function call per listener (if I
properly understood kauth(9))...  Especially if we intend to totally
replace the old system by it.  If I recall we do have architectures with
a high function call cost...  Will such an architecture, possibly a
candidate for securelevel restrictions in an embedded device, suffer
from this?  Or are the costs minimal?

Nonetheless, I do recognize the high flexibility of this system compared
to doing a check against a single global securelevel variable, of
course.  It will allow to integrate a number of nice features.  :)
So far, from the man page, I like the design, but it also made me wonder
about the performance impact, especially as more specific restrictions
get added, a number of LKMs loaded as the kernel becomes more
dynamic/modular, etc

If profiled data and future expectations do show a significant
performance impact, it would probably be a good idea to continue
supporting the less flexible old method instead of obsoleting it
totally, or to review the implementation details of kauth(9). 

Also, could all authorization checks still be disabled as a whole, just
like when we set the kernel to insecure?  Or would this code always be
within the path of common syscalls (although possibly without
listeners)?  If it can totally be disabled, I assume that LKMs could
register new listeners, but that they simply would never be called?

Are there reasons why simply setting a deny flag per scope per security
property wouldn't...
[ message continues ]

No, it wasn't profiled yet. There are no "more restrictions" planned

AFAIK, this is not a consideration. There's no easy way to say it, but
I am simply not working on this with a 486 in mind. Nor with a Vax in
mind, or whatever the architecture(s) you are referring to are...

However.. I *am* trying to make the new code fast as possible. (note:
you are referring *VERY* new code; there have been no efforts to further
optimize it)

I'd like to take this opportunity to state, again, that overhead is to
be expected because we're introducing here a new subsystem (both for
the securelevel-specific cases *and* wherever we're using kauth(9) where
we previously didn't) that does more things. The benefit is rather
obvious, and if the performance of this code on archaic machines is a
consideration that can prevent the integration of kauth(9) in NetBSD,

The performance impact entirely depends on how many listeners each
scope has, and what each of them is doing in order to make an
authorization decision.

Also, why would "a number of LKMs loaded" affect the performance of

Why do everyone keep repeating this? do you have hardware you're
interested in the performance of kauth(9) on? get the code from CVS and
just run it, then post back. I do not have unlimited resources (time



This is simply not how it works. You do not take a step forward to just

Yes. Please, no pseudo-performance improvement suggestions that over
complicate the system, diverge from a known, tested, design, without

The best way you can eliminate (or confirm) your performance concerns
are by testing the code yourself in your own environment.

-e.

-- 
Elad Efrat

Thanks for taking the time to reply

On Sat, 25 Mar 2006 23:28:28 +0200

I somehow thought that the interface allowed LKMs to plug-in "listener"

I hope that it isn't news that NetBSD is also used on embedded systems
which generally require the securelevels functionality...  Such embedded
systems can often consist of a low-end ARM based board for instance.
Possibly a motivation for it's users to worry more about performance and
kernel stack and code size.  It wasn't voluntary on my part to repeat
what others said, but we probably shared a common concern :)

I understand that the traditional behavior of securelevels can be
observed with a new implementation under the new framework, but probably
at a cost (this cost could be very moderate, we however have to find

My vision of the interface includes the scope-specific callback
functions iterator (which I indeed included in "implementation").  Then
of course there are the listeners themselves which can implement the
decisions based on wanted factors, if I understand (probably what you
mean by implementation).  I will reformulate the previous question below

So the question above should have been: Does a kernel configured as
"insecure" avoid even entering the kauth(9) framework, or do they simply
find an empty listeners list?  In other words, does the new interface

I do not understand how using flags, avoiding to iterate over a number
of callback functions, calling each of them, can be called a
pseudo-performance improvement :)  However, as I now read the rest of
the thread (which I should have done before replying), it answered this
question (functions are much more powerful and will allow fancy features

I unfortunately won't be able to test the code very soon but reading it
is on my TODO.  If I have any more questions at least they'll be
informed ones then :)

Thanks again,
Matt

-- 
Note: Please only reply on the list, other mail is blocked by default.
Private messages from your address can be allowed by first asking.

...
[ message continues ]

What you wrote suggested that the performance of kauth(9) may be
affected merely by loading LKMs. Of course that if an LKM adds more
listeners to a scope, there will be a performance hit.

But how many LKMs do you know that do that? :) also, someone who
is loading an LKM is knowingly accepting the performance hit (which,
btw, depends on the LKM, and not kauth(9) itself) and it is up to

If we, again, look at the concerns, there is the code size issue and the
performance issue.

For the first, I already showed that it is very likely that the change
will be around 10kb of change in the resulting kernel image; probably
less. Given that NetBSD's kernel size keeps growing every year, I see
no reason why this should even be a consideration in this case.

As to performance, again, people who suspect a performance hit with the
new code on their embedded/ancient/whatever hardware can just go ahead
and test it. On my machines I haven't seen any performance hit, but then
again maybe the users running i386/amd64 are not so common in the NetBSD
world.

I'd like to ask everyone that before they continue with their chaotic

You keep confusing yourself, and potentially others.

The interface to determine whether a kernel is "insecure" or not is
by "entering" the kauth(9) framework. That is how it works.

People apparently keep replying to messages on this thread without
reading my initial proposal, that addressed the vast majority of
questions that popped up during the discussion.

The NetBSD kernel will no longer check for a single variable, or
multiple variables, to know what state the kernel is in. This is
*exactly* what I want to change. Before proceeding with an operation
that can potentially change the TCB, the request would be dispatched
to kauth(9) for a decision. This is the change in interface.

Obviously, as I repeat again and again, there will be a performance hit
because of the change in interface. But let's examine these performance
concerns a little bit closer, shall we?
...
[ message continues ]

I'd request at least one comparison with some RISC based processor,
MIPS, ARM, SPARC, whatever.  I don't think x86 is "typical", in this
case.  (I think this is important mostly because of possible impact to
embedded MIPS/ARM targets that are likely to be size sensitive.  For
most other RISC workstations, even 100k wouldn't make a difference.)

I'd offer to do it myself, I just haven't taken the time yet.  If no one
else gets to it first, I'll do some tests, but I can't promise a timeline.

    -- Garrett


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191

I hope there aren't any of those folks.  I.e., if you can provide
equivalent functionality (e.g. a template rc script that loads the
sysctls so that the system behaves the same for given securelevels),
then maybe we don't need to keep the old model around, at least not in
the kernel.

Keeping old models like this around doesn't come for free. 
Specifically, costs of doing so are:

    1) additional code size
    2) additional code paths that may or may not get test coverage
    3) additional complexity for users and support
    4) additional documentation impact (if X do Y, else do Z)



Okay.   But this applies to runtime as well.  I'd rather just cut the
cord and go forward, as long as you can reasonably emulate the old

Anything under 10k is negligible.  Anything over 100k is cause for
concern.  There is a big gray area in the middle.  :-)  Basically, if it
makes life much harder for systems with constrained boot media, then it
is a problem.  10k should definitely be less than the threshold of pain,

Big NFS and CVS usage would probably be an excellent way to test
performance.  Maybe also do some kind of database runs, I'm not sure.

My gut is that the performance impact is likely not on the hottest code
paths.   But system call overhead (esp open()) should probably be
checked, because a lot of performance metrics seem to follow that result.

Core of course has the final word, but I suspect some small impact is
tolerable if it shown to be small on the mainstream archs (i386, sparc,
mips, powerpc).

    -- Garrett

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191

Actually, the old model is not really kept, but merely emulated by
the new one. Choosing between "old model" and "new model" can be a
simple thing of changing the default listener code for the system

Okay, so, I don't have my branch sync'd to current, but for a -current
(of March 7th) elad-kernelauth GENERIC i386 kernel, the size I have
is 8668522 bytes. Newer kernel (as of today), also GENERIC, has the
size of 8658790 bytes. That's 9732 bytes difference.

The kauth(9) kernel still includes some of the old interfaces that
should be removed, and I expect the newer kernel to contain some new

I can get around doing some local/over-ssh CVS benchmarks; you're

I expect some overhead. Not too much, but given we now have more code
than we used to to do the same things, we must acknowledge that there
will be some overhead. Like you said, I too don't expect the impact to
be all that critical...

-e.

-- 
Elad Efrat