Re: Legitimate Question

From: Valdis.Kletnieksat_private
Date: Fri Jan 25 2002 - 06:07:54 PST

  • Next message: jmjonesat_private: "Re: Legitimate Question"

    On Fri, 25 Jan 2002 08:20:23 EST, jmjonesat_private said:
    > Yes, thanks to this discussion I see that you are correct.  My question
    > was based on the observation that different modules will use different
    > strategies and, until the target application is actually running, it is
    > not evident from examination of the permissions of various resources if it
    > will actually have permission to access anything.  Shell scripts that use
    > code such as
    > 
    > if test -r filename
    > then
    > ...
    > else
    > ...
    > fi
    > 
    > no longer, necessarily, indicate that the file will be readable by
    > another application running as the same owner/group as the testing script.
    
    I originally thought that our esteemed colleage Mr Jones was good and
    thoroughly high on crack when he started this thread, but now I see
    the issue in question.  autoconf/configure type programs often run tests
    to see if Feature X is available on the system - and good security practice
    says that you do your configure/make work as non-root, and only use root
    for the final install.
    
    Fortunately, on the syscall side, most autoconf tests only see if the
    function is in libc, and don't actually check if the function *works*.
    And for those functions that *do* test, a sane module will probably fail
    it in a way that the autoconf check says it's present.
    
    As far as /bin/test goes, I think the only security-sane way to do
    this is to run the configure step using whatever the module's
    equivalent of the SELinux 'newrole' command.
    
    The next big challenge will probably be getting software writers to
    stop saying "this needs to be set-UID root" or "this needs to be
    set-GID mail", and instead document "this needs to be able to send raw
    network packets" (for ping) or "this needs to bind to port 123 and set
    the system clock" (for NTP) or "this needs to be able to write a file
    in the /var/spool/mail directory" (for an SMTP mail delivery agent),
    so the sysadmin can create/find an appropriate role/class to restrict
    the module at runtime.
    
    /Valdis
    
    
    
    

    _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module



    This archive was generated by hypermail 2b30 : Fri Jan 25 2002 - 06:09:21 PST