lkml.org 
[lkml]   [1998]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: GGI and cli/sti in X


    On Sun, 29 Mar 1998, Chris Evans wrote:
    >
    > Ok, so I'm ignorant. I notice, however, you commented on everything apart
    > from the "finest" point in my post? About securelevel + X? How do we get
    > around that?

    I didn't comment on it, because I don't see this as something that needs
    all that much commenting, it only needs some kind of implementation. I can
    think of many different versions, I don't know which one is necessarily
    the best.

    One option is to require that in order to get into X on a machine that has
    the securelevel set, the machine has to be booted into X (using xdm or
    whatever session manager you want to then use). Then X would get the
    appropriate privileges, and after X has started you "shut the door". I
    don't like that approach, but hey, I wouldn't be the one using securelevel
    anyway.

    The way I'd personally probably prefer (but I don't have very strong
    feelings about this) is to get rid of the old securelevel altogether,
    because it isn't very good. Use bitmaps of capabilities instead, and have
    an extension of the "suid" bit which is a "set-capability" binary.

    In that kind of secure environment the only thing having the "iopl"
    capability would be the X graphics setup binary, and nothing would have
    the capability to add any new "set-capabilities" (actually, even that
    should probably be a bitmask - the bitmask of which capabilities you can
    add to programs).

    The whole concept of "securelevel" was brought about for no other reason
    than that "root" was too strong, and capabilities are fairly obviously the
    way to go. At least _technically_ obviously, I'm worried about the
    complexity and maintenance part of it - people are having problems even
    maintaining a reasonably "setuid root" environment, I despair about doing
    a full capability-based thing (I'm sure good MIS can handle it, but
    there's an awful lot of "mediocre" and "bad" MIS out there too).

    Security is complex, no doubt about it. But the X server is not really all
    that special in this case: the X server happens to need a very specific
    kind of service, but that service is not any more security critical than
    access to the physical disk, for example (or the permission to load a
    kernel loadable module, for example).

    Security is not about denying things: I don't think it is necessarily a
    good idea to not allow loadable kernel modules in a very secure system,
    for example. Security is all about authentication: you must be able to
    load only _trusted_ kernel modules, and similarly you must be able to give
    iopl privileges only to _trusted_ binaries.

    So yes, the X server really implies a certain amount of trust. But you
    trust other binaries on the system - "getty", "login", "inetd", "lpr" etc
    etc. I'm saying that the X server is really in no way unique here. And
    graphics (and X) _is_ so important that I don't see the problem with
    having a trusted X server.

    I wholly agree that the X server currently has unnecessary levels of
    trust: it is one large server that does everything, and as such it is hard
    to validate. But the same is true of sendmail - there are other mailers
    out there that try to do a better job at not exposing the whole mailer to
    being "setuid root", only very small parts. They didn't require kernel
    help for that.

    Linus


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu

    \
     
     \ /
      Last update: 2005-03-22 13:42    [W:0.021 / U:60.828 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site