tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Proposal: Disable autoload of compat_xyz modules



On 31.07.2017 23:39, Taylor R Campbell wrote:
> Many of our binary compatibility modules are notoriously ridden with
> bugs.  We currently have no way to automatically test them.  Some of
> them are maintained; some of them are not.  The value of having NetBSD
> automatically try to execute a SCO Unix binary, for example, seems
> rather weak compared to the security risk of the attack surface.
> 
> So I propose to exclude all non-NetBSD, non-ELF/a.out compat modules
> from autoloading by exec, and remove them from all GENERIC kernels.
> Under this proposal, if you want them in your system, you can add them
> to your kernel config or modload them explicitly.
> 
> This is a compromise between preserving the functionality and reducing
> attack surface for what I hypothesize are a majority of users who do
> not use it.  Under this proposal, the code will remain, and still be
> built, and still be usable -- it will just not be enabled by default.
> In particular, I'm not questioning the value of having (e.g.) Linux
> binary compatibility support; it'll just be one modload away.
> 
> The modules and kernel options that are currently autoloaded by exec
> and/or included in some GENERIC kernels that I propose to disable by
> default are:
> 
> compat_freebsd
> compat_ibcs2
> compat_linux
> compat_linux32

I use both linux and linux32 ones.

> compat_ndis

This one perhaps could stay. It's for network driver.

> compat_osf1
> compat_sunos
> compat_sunos32
> compat_svr4
> compat_svr4_32
> compat_ultrix
> exec_coff
> exec_ecoff
> 
> Do you, or does anyone you know, rely on any of these modules?  Can
> you argue that they *should* be autoloaded by default for the typical
> user, and not enabled explicitly by operators who know they need them?
> 
> Can you tell me who maintains them, or if nobody does, can you
> volunteer to maintain them -- by auditing them, by testing them if
> someone else applies a security fix, by writing automatic tests with
> sample binaries that we can put into atf?
> 
> I'm not asking to delete the code -- only whether it should be enabled
> by default.  If I hear nothing in one week, then I will disable these
> by default, and a week later, I will request pullups to netbsd-7 and
> netbsd-8.
> 
> 
> P.S.  The old-NetBSD, a.out, and 32-bit compat modules may be broken
> too, and are probably not automatically tested either, but are more
> likely to be manually tested and I'm not addressing them right now.
> These are:
> 
> compat (i.e., old-NetBSD binary compat)

I use NetBSD-0.9 executables and they work for me.

> compat_aoutm68k
> compat_netbsd32

Works for me.

> exec_aout

Works for me.

> exec_elf32
> exec_elf64
> exec_script
> 


Attachment: signature.asc
Description: OpenPGP digital signature



Home | Main Index | Thread Index | Old Index