Re: ifupdown writes to /etc... a bug?
Russell Coker <russell@coker.com.au> writes:
> On Sat, 22 Mar 2003 22:00, Thomas Hood wrote:
> > Russell Coker wrote:
> > > Why force developers to do more work for a ro root
> > > than is being done for more serious security measures.
> >
> > The two measures aren't mutually exclusive.
> >
> > Is it a lot of work to implement /run?
>
> If it was not a lot of work then it would have been done without such a long
> discussion.
It has been done.
deb ftp://mrvn.homeip.net/ sid main
deb-src ftp://mrvn.homeip.net/ sid main
Now it has to be approved.
> Really good ideas are not known for being complex and fiddly to implement,
> really good ideas often hit you with a "doh, this is to easy that I should
> have solved it when I was a 10yo" moment. When something requires huge
> amounts of hackery you have to question whether it's desirable.
>
> I believe that the people who want a ro root FS are in a tiny minority, and
> that things can be best solved if they hack the few scripts in question
> themselves. Such people undoubtedly have other unusual requirements and are
> hacking things to their own desires anyway.
Currently thats not feasable since you have to patch several packages
and recompile them on every software update. And everyone would have
to do that.
> > If it is decided
> > that the idea is sound, then maintainers can just start
> > moving their run-time state files under /run. Also,
> > somewhere must be documented the new requirement that
> > /run must be rw, local, and persistent-until-reboot --
> > whether it be a directory on the root filesystem or a
> > tmpfs or whatever. Then there is getting the FHS
> > changed; that will be the most work.
>
> Things to do:
> 1) Change programs such as mount.
sysvinit and mount is changed. ifup/down is next.
> 2) Solve issues of supporting different kernels (2.2.x doesn't have tmpfs).
Thats a non issue. The way I changed the packages is to be fully
functional the way everything is now with the option of a /mem
filesystem and a linked /etc/mtab. Noone has to change anything unless
he wants a RO /. And then he can use any kernel and any filesystem for
his /mem.
> 3) Convince the FHS people (as if that's ever going to happen).
That where the force of debian as distribution would have to help pushing.
> 4) Change all applications that write to /etc and put in sym-links for
> applications that read from it (*).
Isn't that covered by 1?
> 5) Deal with on-going issues because almost no developers run their machines
> in such a fashion.
If it where possible more people would.
> (*) A short list for 4 is:
> mount
> Some file system administrative programs.
(raid, lvm)
ifup/down
/etc/resolv.conf (dhcp, ppp)
Those should be the only programs to change. Only programs neccessary
to get the system up need some place to write before /var is up and
/etc/resolv.conf is probably to hard to move somewhere else.
> passwd/chfn/chsh/etc
> useradd/userdel/etc
dpkg, dselect, apt
Those are administrativ tools. You wouldn't run those with a RO
/. There are config examples for apt that automatically mount / RW
before apt and RO afterwards.
/etc/passwd can be managed via network easily enough and isn't realy a
high priority problem for RO / I think.
> sendmail daemon
> sendmail -t run by the user for some mail servers
> Various daemon start scripts.
> ntpd
> hotplug
> samba
Why would they ever need to write to /etc? They can and should all use
/var for machine writeable files.
> The problems don't end here however. One thing to consider is that
> increasing complexity is the enemy of security. The idea for /run
> may help security on a small minority of systems at the cost of
> making things needlessly more complex on the majority of systems.
No changes on systems without /mem needed so far. So not realy an argument.
>...
> Now back to the original issue of writing to /etc. I don't have a problem
> with having a different location for such writable files. I believe that
> having a clear separation between writable files and read-only files is a
> good thing as it simplifies system administration in many ways. For daemons
> using /var for such files is already the recommended policy.
Lets make /var mandatory for non boot essential tools.
> As we already do this for the easy things, wouldn't it be easier for someone
> who wants to do this to just maintain a repository of modified packages to
> provide this?
Then you have two maintainers and two repositories doing the same
work.
MfG
Goswin
PS: Anyone against forbidding write access in /etc for anything but
boot essential tools?
Reply to: