Re: Reflections on Trusting Trust

From: Andreas Nemeth (andreas.nemeth_at_aporem.net)
Date: 11/30/05

  • Next message: Alexander Leidinger: "Re: Reflections on Trusting Trust" 
    To: freebsd-security@freebsd.org
Date: Wed, 30 Nov 2005 13:36:10 +0100

    On Wednesday 30 November 2005 09:55, Ádám Szilveszter wrote:
    > 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.

    Second that. But I feel a little uneasy about making /usr/ports/ group
    writeable for wheel or giving it to a "normal" user on the system.
    What about creating a user called "ports" or something more compelling? Most
    daemons have their own uids, so why not "the daemon" for downloading an
    compiling?

    > (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.)

    And what about the +INSTALL and +DEINSTALL scripts, some ports want to run?
    Those I've seen, ensure that a certain user exists. Therefore they roam
    around in /etc.
    BTW, those scripts fail (of course), if /tmp is mounted with the noexec
    option. So the nightmare begins with root re-mounting /tmp rw, fetching the
    distfiles and storing and executing shell scripts on /tmp...

    > Best regards,
    > Sz.

    Best regards,
    Andreas
    _______________________________________________
    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: Alexander Leidinger: "Re: Reflections on Trusting Trust"

    Relevant Pages

    • Re: freebsd-questions Digest, Vol 184, Issue 3
      ... Starting again from Scratch ... Re: Starting Scripts ... Repopulating the GENERIC kernel ... script to update my ports tree ...
      (freebsd-questions)
    • SUMMARY and apology Re: Some bash/tty questions
      ... Some people tend to create complex login scripts ... If you don't allow direct login to root, but rather su to root, then so ... Hi, not to bash down on bash, but perhaps you should try zsh, it has the shared history thing built in. ...
      (SunManagers)
    • Re: automake, autoconf compiling
      ... scripts are indeed very platform independent. ... > reason why the FreeBSD ports infrastructure needs to play so many ... the reason the Ports go through all the hoops you see is that they ... One other reason is, of course, the fact that the autotools have changed ...
      (freebsd-newbies)
    • Re: automake, autoconf compiling
      ... scripts are indeed very platform independent. ... > reason why the FreeBSD ports infrastructure needs to play so many ... the reason the Ports go through all the hoops you see is that they ... One other reason is, of course, the fact that the autotools have changed ...
      (freebsd-questions)
    • Re: Primary Differences: FreeBSD/Linux
      ... > shell for scripts, ... Some do, it's in ports. ... ports tree or package tools from a console command line. ...
      (comp.unix.bsd.freebsd.misc)