Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 05 Feb 2010 12:04:47 +0100
From:      Jordi Espasa Clofent <jespasac@minibofh.org>
To:        freebsd-stable@freebsd.org
Subject:   Re: Inmutable bit in some binaries
Message-ID:  <4B6BFB4F.5010505@minibofh.org>
In-Reply-To: <20100203134025.GA1787@icarus.home.lan>
References:  <4B696D0B.3070301@minibofh.org> <20100203134025.GA1787@icarus.home.lan>

next in thread | previous in thread | raw e-mail | index | archive | help
> It's possible installworld will break (fail/exit) when trying to
> overwrite some of these binaries.  However...
>
> install(1) supports the -f flags to specify what the destination file
> should have its file flags (chflags) set to, and from looking at the
> code (src/usr.bin/xinstall/xinstall.c), there are some places which
> indicate before copying/installing a file the software may attempt to
> unset file flags first.  I'm not 100% familiar with this code, but it
> appears as if use of the -S flag to install(1) would cause it to behave
> like described.  It should be easy enough for you to test.
>
> Otherwise, my recommendation is to build a test system / virtual box of
> some sort (VMware, etc.) and try it.  See what happens.

Ok. It's exactly what I've supposed.

> Opinion below:
>
> What you're attempting to solve, ultimately, is security through
> obscurity and gets you a very large headache.  :-)  Your schg idea would
> only work if you planned on using kern.securelevel=1 or higher.  This
> sounds great in concept, but many a time on this list have people posted
> problems with system administrative tasks (re: upgrading) when this
> sysctl is set to non-default (-1).

Mmmmmm... I don't undestand this like secuiryt by obscurity; anyway 
you've the reason: kern.securelevel should be the correct path to follow.

> If you plan on using this, I would advocate *all* installation/work be
> done in single-user mode.  I know quite a few people who completely
> ignore the "boot into single user" step of src/Makefile and instead do
> it in multi-user mode -- only to be found later screaming/crying when
> binaries don't work or behave oddly because, say, /libexec/ld-elf.so was
> supposed to be updated yet wasn't due to their choosing to not follow
> the proper procedure.  If your system doesn't have an out-of-band
> method of getting to it (ex. serial console), then I wouldn't bother
> trying any of the above.
>
> Otherwise, I'm pretty sure others here have made use of read-only
> environments, such as read-only NFS root filesystems (sometimes
> accomplished via PXE) and/or /usr, or CD-based OS (good luck changing
> any files there).  I can't help in that regard.

Thanks for comments. ;)

-- 
I must not fear. Fear is the mind-killer. Fear is the little-death that 
brings total obliteration. I will face my fear. I will permit it to pass 
over me and through me. And when it has gone past I will turn the inner 
eye to see its path. Where the fear has gone there will be nothing. Only 
I will remain.

Bene Gesserit Litany Against Fear.



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