tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: openat/fstatat functions implementation



Unrelated to the thread, but

Christos Zoulas wrote:

Well, still that does not solve the void * problem... And think about it
a different way. One of my biggest annoyances in the kernel is the way
kauth passes arguments trying to homogenize calling conventions and abusing
void * for varargs. I don't want to have to debug syscall code doing the same.

I've heard that several times. Here's the thing: The real work when
improving the security infrastructure is not the interface used, but
rather how it's used. In other words, the kauth(9) back-end is just
there to allow us achieve something that we want regardless of the
actual interface, which is identifying code that needs to be
abstracted, what exactly it does (yes, not many people know what every bit of code does and how it affects different platforms apparently),
properly separate and centralize secmodel decision (i.e., scattered
checks -> suser and securelevel), etc.

Once all that is in place, replacing the KPI can be done very easily
either scope-by-scope or altogether; it doesn't really matter as the
functionality is what's important.

When we started implementing kauth(9) (2005? 2006?) no BSD went all
the way with completely centralizing its security framework. In fact, I
think even FreeBSD still has tons of security related checks in its
code: securelevel_gt(), priv_check(), MAC framework hooks, jail hooks...
These may all be "type safe" and without void * arguments, but take a
look at cr_cansignal() for example:

        http://fxr.watson.org/fxr/source/kern/kern_prot.c#L1435

It has prison_check(), mac_proc_check_signal(), cr_seeotheruids(),
cr_seeothergids(), priv_check_cred(), and open-coded uid matching
followed by another pric_check_cred().

Without getting into a discussion about design decisions, I think the
path we're taking fits us better than the alternatives for reasons
ranging from the results, developer and user involvement, to perhaps
the way development is done (kauth(9) wasn't developed as part of a
TrustedNetBSD :). So if you're worried about passing void * arguments in
kauth(9), please be patient. :)

-e.


Home | Main Index | Thread Index | Old Index