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



On Wed, May 23, 2007 at 09:38:46AM -0700, Colin Percival wrote:
FreeBSD architects and file(1) maintainer,

I'd like to remove file(1) and libmagic(3) from the FreeBSD base system
for the following reasons:
1. I don't see it as being a necessary component of a UNIX-like operating
system.
2. It's available in the ports tree.
3. Due to its nature as a program which parses multiple data formats, it
poses an unusually high risk of having security problems in the future
(cf. ethereal/wireshark).

Do either component do much parsing/reformatting of data? The major
drawback to wireshark is that it has to accept <N> different formats and
display them in human readable form. To do that it doesn't use a common
translation codebase with mapping files (which is what 'file' does), it
has <N> different binary parsers which each introduce their own
potential problems. Unless I'm missing something, all
file/libmagic have to do is look for binary signitures in the file
that identify it as being of a specific type.

The scope for file may have creeped over the years, but I do not see
the functionality needed in file as being anywhere close to the song &
dance that wireshark goes through, and as such I am not sure I
agree with your comparison.

The "file" program has been around as a standard part of UNIX and UNIX
clones for a long time, and unless there is an endemic problem with
the way the code works I personally would not be supportive of this move.

The one redeeming feature of file/libmagic as far as security is concerned
is that it doesn't act as a daemon, i.e., other code or user intervention
is required for an attacker to exploit security issues. This is why I'm
asking here rather than wielding the "Security Officer can veto code which
he doesn't like" stick. :-)

Can anyone make a strong argument for keeping this code in the base system?

Colin Percival
FreeBSD Security Officer

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


_______________________________________________
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: freebsd-security Digest, Vol 120, Issue 1
    ... Adding OpenBSD sudo to the FreeBSD base system? ... Usually I've installed it as a package off the install CD, ...
    (FreeBSD-Security)
  • Re: [Removal of mrouted in FreeBSD-7.0]
    ... What are the things that needs to be considered if we are going to implement PIM-SM and or PIM-DM to the current FreeBSD network subsystem? ... The goal is to be able FreeBSD to provide native IP multicast using PIM just like the way DVMRP protocol is implemented before as part of the base system. ... I really think the remit of multicast routing is too wide to be addressed in the base system, which is why projects like XORP and pimdd exist -- it doesn't strike me as a good fit for the FreeBSD base system. ... Separate projects already exist for this. ...
    (freebsd-net)
  • Re: /usr/ports vs. /usr/src/contrib (was: In 9.0-RELEASE, does swapping to a ZFS swap device wor
    ... or lack the patches the versions in the ... base system have to better fit in with building the FreeBSD base system. ... ports tree are vanilla, then patched to work with FreeBSD. ...
    (comp.unix.bsd.freebsd.misc)
  • Re: Damn you, FEDEX! or Nikon D40 lost in Springfield, MO blackhole.
    ... the 2 mp Mavica he had been using with a Nikon D40. ... After shopping around, he got me to order one for him. ... The shipper had it insured, but from what I have read it could take weeks to sort this crap out. ... You may get your insurance from FedEx and a couple weeks later they find it and deliver it. ...
    (alt.photography)
  • Re: RFC: Removing file(1)+libmagic(3) from the base system
    ... FreeBSD architects and filemaintainer, ... I'd like to remove fileand libmagicfrom the FreeBSD base system ... The one redeeming feature of file/libmagic as far as security is concerned ... Can anyone make a strong argument for keeping this code in the base system? ...
    (freebsd-arch)