lkml.org 
[lkml]   [2005]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature
    From
    Date
    Ingo Molnar <mingo@elte.hu> writes:

    > i believe RT-LSM provides a way to solve this cleanly: you can make your
    > audio app setguid-audio (note: NOT setuid), and make the audio group
    > have CAP_SYS_NICE-equivalent privilege via the RT-LSM, and then you
    > could have a finegrained per-app way of enabling SCHED_FIFO scheduling,
    > without giving _users_ the blanket permission to SCHED_FIFO. Ok?

    Yes, we designed the module with this scenario specifically in mind.

    > this way if jackd (or a client) gets run by _any_ user, all jackd
    > processes will be part of the audio group and can do SCHED_FIFO - but
    > users are not automatically trusted with SCHED_FIFO.
    >
    > you are currently using RT-LSM to enable a user to do SCHED_FIFO, right?
    > I think the above mechanism is more secure and more finegrained than
    > that.

    We *are* doing that (based on group membership). We designed it just
    as you say. And it works fine for Qt and command line clients.

    Unfortunately, GTK+ refuses to cooperate. It has a special check at
    startup (in gtkmain)...

    if (ruid != euid || ruid != suid ||
    rgid != egid || rgid != sgid)
    {
    g_warning ("This process is currently running setuid or setgid.\n"
    "This is not a supported use of GTK+. You must create a helper\n"
    "program instead. For further details, see:\n\n"
    " http://www.gtk.org/setuid.html\n\n"
    "Refusing to initialize GTK+.");
    exit (1);
    }

    Note that this calls *exit(1)*, not just returning an error code.
    Following the suggested URL, <http://www.gtk.org/setuid.html>, reveals
    their understandable, but basically wrong-headed, rationale...

    GTK+ supports the environment variable GTK_MODULES which specifies
    arbitrary dynamic modules to be loaded and executed when GTK+ is
    initialized. It is somewhat similar to the LD_PRELOAD environment
    variable. However, this (and similar functionality such as
    specifying theme engines) is not disabled when running setuid or
    setgid. Is this a security hole? No. Writing setuid and setgid
    programs using GTK+ is bad idea and will never be supported by the
    GTK+ team.

    They are wrong (IMHO), because these kinds of security tests *cannot*
    reliably be done in userspace. They are not testing for possession of
    privileges, but merely disallowing two of a half-dozen ways of
    granting those privileges. Why should it be OK to run GTK as `root',
    but not as setgid `audio'? Ironically, people don't run GTK threads
    with SCHED_FIFO. Those are precisely the threads over which the
    signal processing threads need to have priority.

    This "feature" has forced us to fall back on supplementary groups for
    our main authorization mechanism. That is unfortunate because, as you
    say, the setgid() approach has finer granularity, which is better.
    So, that GTK test has the unintended consequence of making our
    security exposure larger, not smaller.

    We can live with this, mainly because our users often need
    supplementary membership in group `audio' anyway, to gain access to
    the sound card.

    If we can ever convince the GTK developers to remove this "feature",
    the RT-LSM handles setgid() correctly. So, we could immediately start
    using it (at least on systems with a new enough GTK library to permit
    that).
    --
    joq
    -
    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 14:10    [W:2.467 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site