Re: Reflections on Trusting Trust

From: Qd=E1m_Szilveszter?= (adamsz_at_mailpont.hu)
Date: 11/30/05

  • Next message: Kris Kennaway: "Re: Reflections on Trusting Trust"
    Date: Wed, 30 Nov 2005 09:55:24 +0100 (CET)
    To: freebsd-security@freebsd.org
    
    

    On Sze, November 30, 2005 12:43 am, Colin Percival mondta:
    > Even before you get to that point, you have to worry about making sure
    > that the build clients are secure. One possibility which worries me a
    > great deal is that a trojan in the build code for a low-profile port
    > (e.g., misc/my-port-which-nobody-else-uses) could allow an attacker to
    > gain control of a build client (and then insert trojans into packages
    > which are built there).

    Which practically begs the question: could we, pretty please, change the
    defaults and stop encouraging people from downloading distfiles and
    compiling them when using the ports tree as *root*? (shudder) There is
    exactly zero reason for this that I can think of apart from some "well
    it's more convenient that way" arguments. With the current model of using
    ports (and packages too) every single BO or whatever in eg fetch or
    libfetch becomes a sure-fire remote root vulnerability, because all
    FreeBSD machines use fetch to retrieve stuff from random sites on the
    Internet (MASTERSITEs are all over the place) as root. A security
    worst-practice. (Well, not all of them... I use a non-priviledged user to
    do that, which is now becoming more and more practical, but earlier there
    used to be all kinds of nasties in the build processes of certain ports
    which you only noticed if you were non-root...)

    (Of course, we could go even further and start compartmentalising access
    rights because eg a user with port-install rights should have no
    permission to touch the base system, in partcular system binaries and the
    contents of /etc, but this would also require saying farewell to some
    really bizarre things like "openssh from ports overwriting the one in the
    base" which would be really a good idea btw.)

    Best regards,
    Sz.

    -----------------------------------------------------
    1 GByte ingyenes e-mail és webtárhely a MailPont-tól!
    Miért fizetnél érte, ha nálunk teljesen ingyen van?
    Regisztrálj te is magadnak! - www.MailPont.hu -

    _______________________________________________
    freebsd-security@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-security
    To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"


  • Next message: Kris Kennaway: "Re: Reflections on Trusting Trust"

    Relevant Pages

    • Re: Destined to be hacked?
      ... > 1 - What is the risk involved in having a non secure password on a non ... Of course they need to know the login name too. ... Just see to that people can't login as root, this makes it more difficult to ... > people sit there and scan ports just looking for anyone as well. ...
      (alt.linux)
    • Re: Destined to be hacked?
      ... Of course they need to know the login ... > to try out password for root user. ... >> people sit there and scan ports just looking for anyone as well. ... > installation, if you add php, avoid to use scripts that allows people to ...
      (alt.linux)
    • Re: Ports 0-1023?
      ... privilege seperation using the Linux capabilities. ... >>Is there any point in needing to be root in order to allocate the low ... >>of ports? ...
      (Vuln-Dev)
    • Re: Ports 0-1023?
      ... > Is there any point in needing to be root in order to allocate the low ... > simply be used that says a particular UID can allocate a particular range ... > of ports? ... Let's say you don't need to be root anymore. ...
      (Vuln-Dev)
    • Re: Reflections on Trusting Trust
      ... > Internet as root. ... What about creating a user called "ports" or something more compelling? ... And what about the +INSTALL and +DEINSTALL scripts, ... BTW, those scripts fail, if /tmp is mounted with the noexec ...
      (FreeBSD-Security)