I made a stupid post elsewhere in this thread and recognised it. But
here I'm far from convinced I should have shut my big mouth :-p
Cameron Simpson wrote:
> [...]
> | Reading proc files requires running kernel space code, do we have kernel
> | space code running with *user* priviledge now?
>
> Oh please don't inject (more) noise into this1 Doing ANYTHING involves
> running kerel space code somewhere.
Nothing to do with my point. You can't make usefull code without kernel
syscalls sure but you don't need kernel code for most of your code.
We speak of code priviledge here. If you put the whole dmidecode in
kernel space you make it running at full system level priviledge. So
there's little difference (and in fact favorable to suid solution) to
the priviledge level of the running code. Point.
Anyway this thread branch is dead, we didn't understand Eric's point
which was on the level of priviledge the *user* using the code needs.
> It is still possible to talk
> meaningfully about:
>
> - opening a publicly readable file in /proc to get some info,
> which will run some kernel code (which can presumably be trusted;
> if you don't trust your kernel you have a serious problem)
I have different levels of trusting. For example I trust code I've read
and understood (somehow did program proof) as much as I trust my
capability to understand the code. So in short I don't fully trust
anything but have more confidence in some things (experience running it,
heard good things from people I *trust*, ...).
> versus
>
> - running a setuid binary (however audited) to get the info; said
> binary may have bugs, security holes, race conditions etc;
These aren't things kernel code is immune to.
> it may be
> hacked post boot (no so easy to do to the live kernel image), etc
>
Hacked post boot <- security bug outside of dmidecode. If security is of
concern this bug should be corrected with or without existance of an
user-level dmidecode.
You mean probability of bug greater out-of-kernel than in-kernel ? I
don't deal with such things as bug probabilities on corner cases like
this, sorry. If you have enough security bugs in a corner case of
reading (not even writing to) /dev/kmem (BIOS tables, not kernel data)
to make probabilities I don't trust your systems :-p
> Further, binaries which grovel in /dev/kmem tend to have to be kept in sync
> with the kernel;
Read dmidecode.c, it's an exception.
> in-kernel code is fundamentally in sync.
>
Wrong, history shows there are always parts of the kernel behind.
LB.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 07 2002 - 21:00:22 EST