Hi, in SuSE 11.1 since 2.6.27.23 kernel a /proc filesystem appeared in /var/lib/named. Do you know any reason, and/or how to get ride of it ? It may pose a risk to my domain. It my system under a serious attack ?
Nothing to do with the kernel version and all to do with named running chrooted in /var/lib/named. Named obviously needs some entry in /proc to function and the way to provide that in a chroot environment is to bind mount /proc at the top of the chroot. You will see that a similar thing is done for ntpd in /var/lib/ntp.
Thank you Ken. Still one may ask what is the sense of chroot if one can access fs by /var/lib/named/proc/1/root !
Access ot /proc/1/root is still controlled by access permissions whether chrooted or not. What chroot does is remove casual access to the majority of the other files under /. Chroot is not a magic solve-all for security. It has to be combined with other measures. For example named runs as named, not root.
What do you mean with “casual access to other files” ? Under prosc/1/root one can access all files as if there were no chroot at all. I see no gain with this named chroot at all !
You’ll probably want Ken to clarify this a bit but IMO you’re looking at it wrong. You need to be looking at it from the chroots point of view.
[Root Tree] -> [chroot]
You see it is one way, with some major over simplification and as Ken pointed out if you have the tools there is nothing stopping you [chroot[Root Tree]]. Think of it as a lobster basket once in you “Can’t get out” but if outside it, you can do what you want.
Sorry, I don’t undestand. With the former chrooted named version I couldn’t access root files, with the current one I can do it.
You’ll need Ken’s input I have only some crude understanding of chrooting, I would guess the chrooting is being done for a reason.
Now on some brief googling and due to lack of knowing where to look properly for this bind-chrootenv-9.5.0P2-18.1.i586 RPM I notice that the changelog has several references “… to change root jail.”
As for reasoning’s you may need, Ken’s input.
Yes, but so what? A non-root account will get permission denied if it tries to open those root files in /proc. The usual id based permission rules apply to files in /proc. Named is running as named, not root. If you do your experiments as root, you will get the wrong impression.
It’s better not to simulate something, which the solution don’t really offer and to run named without such chroot, or to go back to named version, which don’t access /proc.
I don’t know what you are on about. What simulation?
Do not confuse the root in the word chroot for changing to root account. It doesn’t mean that. It means changing the root directory for that process. A more accurate term is a jail.
Chroot vs running as root id are totally different and unrelated concepts.
If you are a root process, you can escape a chroot jail. This is a fact. So chroot jails are not effective for root operated processes. That’s why named doesn’t run as root. Running named inside a jail does not increase the danger compared to running named outside the jail, which would also have access to /proc (the real one, not the bind mounted one). It improves the security because you hide all the other files that you would see in the normal filesystem. But a key part of the effectiveness is running as non-root.
Ok, it was my mistake. I entered:
cd /var/lib/named/proc/1/root and I found myself in / i.e. I escaped from the jail !
What I have overseen is that the last directory from the path from above (i.e. root) is only the symbolic link to “/”. This means, that in a “named” process after a chroot("/var/lib/named") system call “cd root” don’t changes the direcoty to the “/” but to the new root i.e. to “/var/lib/named” and one cannot escape a jail. This is true independant from the effective user id, who makes this calls. Even the user root cannot escape from the /var/lib/named jail !
Thank you for your patience
No, a root process can escape a chroot jail. You just haven’t found the steps to do so. I leave the homework to you. 