Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 23 May 2007 14:29:27 -0400
From:      Gary Palmer <gpalmer@freebsd.org>
To:        "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>
Subject:   Re: RFC: Removing file(1)+libmagic(3) from the base system
Message-ID:  <20070523182927.GF28958@in-addr.com>
In-Reply-To: <46546E16.9070707@freebsd.org>
References:  <46546E16.9070707@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
> 
> 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070523182927.GF28958>