running freebsd in read only mode

Lowell Gilbert freebsd-questions-local at
Sat Apr 19 09:27:14 PDT 2003

kitsune <kitsune at> writes:

> On Sat, 19 Apr 2003 07:20:19 -0700 (PDT)
> Dan <suedes098 at> wrote:
> > Hello,
> > 
> >    I'm looking into how i can run freebsd in read-only
> > mode. I looked around for info on this, but was
> > unsuccesful at finding anything that helped me in my
> > particular situation. I'm involved in a security
> > contest kind of like defcon at my college. Of course i
> > picked FreeBsd as my O.S. to secure. I am on the
> > defensive side of the game, and get points for the
> > more access and services i allow to the attackers. So
> > here is the situation. What i would like to be able to
> > do is boot into freebsd and have it be completely
> > read-only. For example, if i give a user shell access
> > they can't change anything, they can use the programs,
> > but not create or delete anyfiles what so ever. I want
> > to be able to run a lot of services, and not allow
> > succesful attacks to change anything on the compute
> > that way they can have telnet and all the weekest
> > protocls freely open, and even if they sniff my
> > administration password through a man in the middle
> > attacker or what not they can't change it or do
> > anything to affect the comp.
> >     Any suggestions, or help would be greatly
> > appreciated.
> > 
> >    Dan
> It is possible of mounting everything that is needed as read
> only. But that won't a dif if ye are running services that are not
> secure since thay will continue to present a threat. If they can get
> the root password it does not make a dif since then the can just
> easily be remounted so it is writable.

This is ignoring securelevels (which can keep mounts from occurring or
changing), file change flags, and the possibility of using media that
really are read-only (like CD-ROMs).  It's still theoretically
possible to get around these, but without access to the physical
console, it probably requires directly modifying tables in a running
kernel.  Distinctly tricky.

> Like in other OSes, it is best not to take stupid risks with
> dangerous services and make sure all the file permissions are good.

No question.  In the kind of contest in question, though, the
definition of "stupid" risks is a bit different from our everyday

More information about the freebsd-questions mailing list