netfilter firewalling problems and solutions

Robert Connolly cendres at videotron.ca
Fri Feb 20 14:30:19 PST 2004


On February 20, 2004 02:49 pm, Archaic wrote:
> >More logic for files in /etc too.
>
> The problem with this is that if you modify a file in /etc, it will show
> up on the rescan as being newer. The a config file for apache is sitting
> in the proftpd install log.

If everything is immutable then nothing will be modified. /var/log can be 
ignored because logs don't need to be deinstalled. I don't think I want 
anything installing to /etc automaticly. The install log, and /etc files 
would need to be checked by hand after make install. Uniq can check install 
logs to make sure no two logs have the same entery.

> > When a package is reinstalled, it should be deinstalled first.
>
> With careful note to wipe any hardlinks as well, though a kernel patch
> can stop the link attack, and tripwire will tell you if the link count
> has changed, but I just wanted to keep this thought in mind.

There is an old post, maybe to security@ from decemberish. I think there is a 
way to hardlink to an suid binary, so if its deinstalled and reinstalled, the 
user can run the old binary, which might be lacking security fixes that are 
in the new one. I've also seen this attack described on the coreutils ml.

> > like libc the system should boot an initrd to upgrade, so the deinstall
> > doesn't break running the system. A framework like this can still be used
> > by rpm, apt-get, etc, or just simple tarballs and a few commands.
>
> I like the initrd idea. What did you have in mind to protect someone
> from rebooting to the initrd or modifying it?

The same method that prevents a non-pax or non-selinux kernel from booting. 
The admin needs to keep those kernels off the computer. But, if a user is 
able to reboot your machine, they're also able to overwrite the kernel 
(usually).

> > I've also considered installing chap5 to /stage1, and chap6 tools to
> > /tools. So the compilers can be unmounted, or network mounted. This could
> > work well with crosscompiling too. And if non-root users build packages,
> > it might help to let user lfs own /tools on the finished system, while
> > root still owns the real system.
>
> What purpose would it serve? If someone rooted, it doesn't matter who
> owns the compiler bins. If someone gains user lfs privs you're equally
> at risk. If they are owned by root, they can only be attacked by the root
> user leaving a smaller avenue of attack. Of course, I may not be seeing
> the whole picture...

I can't think of a good reason why lfs needs write permission to /tools after 
chap6. And I can't think of a good reason root should be installing /tools. 
But if chattr +i is being used between installs, root would have to do that, 
along with chown; but switching back and forth is messy. If user lfs doesn't 
have a password, and root has to su down to login as lfs, then I dont think 
it opens up much vulnerabilities.





More information about the hlfs-dev mailing list