lkml.org 
[lkml]   [2002]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: ISA slot detection on PCI systems?
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:15    [W:2.532 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site