Re: RFC: Removing file(1)+libmagic(3) from the base system

M. Warner Losh wrote:
I would argue that it would make the system LESS secure, because one
loses the ability to identify files on the system. People are going
to install it anyway, and it is a jump ball as to whether having it in
the base system would cause vulnerabilities to be updated faster than
having it in ports (both the actual update in the system, as well as
the user causing the update to happen: ports are a touch easier to
update, but lag a bit both in terms of people updating their ports
tree and ports committers updating the port).

Interestingly, my experience from portsnap is that people tend to update
ports more frequently than they apply security patches to the base system.

And for there to be any exploitable vulnerability, the attacker would
need to feed the victum a bogusly formatted file, and cause the victum
to run file on that file. I doubt that the latest security hole will
ever result in a system compromise...

You're more optimistic than I am, then. This latest advisory was issued
on the basis of "it's a heap overflow in rather messy code, so we really
have no idea if it's exploitable".

I guess I fail to see how this is any different than the .gz bugs that
were found a while ago. Nobody suggested removing .gz from the tree
because a few bugs were found. Everybody suggested updating right
away to fix those bugs. File is no different, and really should
remain in the tree.

Deflate is one file format which is used quite often. File parses several
different formats, including several which are not tested often (i.e., have
a much higher chance of including parse bugs).

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

Relevant Pages

  • RE: Reflections on Trusting Trust
    ... > tree - which gets back to the issue of trusting the FreeBSD distribution. ... Anyone who is between you and freebsd cvsup server can make his own ports ... yet, installing a ca-root certificates port, downloading a public key or ... resynching your ports tree implies on network transmission of certificates, ...
    (FreeBSD-Security)
  • Re: Totally lost
    ... There is a target there for "updating" the tree via ... that it's not in the ports. ... what's the difference in using cvsup or portupdate to update the ... (I can only assume that if there's such a thing as 'portupdate', ...
    (freebsd-questions)
  • Re: [OT] CVSUP (was "Re: Was: Re: Why This Infinite Loop??")
    ... if he is not familiar with the FBSD ports system. ... supposedly an advantage of portsnap. ... The protocol uses no encryption or signing, and any attacker who can intercept the connection can insert arbitrary data into the tree you are updating. ... this means that anyone who can compromise a CVSup mirror can feed arbitrary data to the people who are using that mirror. ...
    (freebsd-questions)
  • Re: RE: Portage tree
    ... > have it installed in your system you can install it from ... You can actually update the ports tree in 3 ways I've found and I used them ... A new tree is built after the FTP is completed. ...
    (freebsd-newbies)
  • Re: Driver Update Disk discussion
    ... :> One does not need to patch the source tree at to pick up ports modules ... One can build the ports modules as part of the ... :> kernel by simply defining PORTS_MODULES in a kernel config file. ...
    (freebsd-hackers)