lkml.org 
[lkml]   [2009]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Q: selinux_bprm_committed_creds() && signals/do_wait
    Date
    The SIGNAL_GROUP_EXIT check is fine for now.  But we should revisit this
    area more thoroughly at some point. (That is a low-priority thing.)

    There is a wrinkle here I don't like. The fatal signal is "committed to"
    (sender approved by security modules, etc.) "before" the exec, but gets
    delivered "after" the exec. e.g., acct_process() writes a record for the
    killed process showing the uid/gid from after the setuid/setgid exec, when
    security would not have allowed the killing signal to be sent after the
    exec, only before. Obviously this is a minor quirk (not to be worried
    about today), but it points to a deeper kind of "wrong" that troubles me.
    I can't think of any other similar wrinkles that could be observable at
    all (or matter more than that one), but there might be another.

    This is related to the issue of racing stop signals lost by de_thread().
    That is still on our back-burner list to think about more deeply one day.
    We don't need to contemplate any of this much more right now, but I would
    like to address the whole mess better later on.

    I don't understand why install_exec_creds() is called as late as it is.
    Can't we do that in flush_old_exec()--you know, where it says:
    /* install the new credentials */
    ?

    What I think would be best is if flush_old_exec() does all the "point of no
    return" logic and that includes the credentials changes. Then we can
    define this as the point of transition from "before exec" to "after exec".
    It would do the final check for signals interrupting the exec, and if
    flush_old_exec() returned 0, then any "new" signals are "after exec".
    We'd reorganize things so the final creds switch is under siglock.
    Then either a sender precedes the exec and any security module's flushing
    logic wipes the pre-exec state as it wants to, or the sender follows the
    exec and is subject to signal security checks based on the new credentials.


    Thanks,
    Roland


    \
     
     \ /
      Last update: 2009-05-01 02:17    [W:3.480 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site