Why is the immutable bit of all system binaries viz files in /sbin, /bin, /usr not set, so that none can change or delete them?
as you can see chattr /bin/login will give ------------- /bin/login
--
Regards
Preeti Malakar 2nd year of M.Tech in CSE Indian Institute of Technology Guwahati India
preeti malakar wrote:
Why is the immutable bit of all system binaries viz files in /sbin, /bin, /usr not set, so that none can change or delete them?
as you can see chattr /bin/login will give ------------- /bin/login
As Paul said, that would stop yum and rpm from upgrading those programs (say if the immutable binary has a security bug).
Most of them are owned by root: other users can't change them anyway, due to file permissions. And root has the ability to remove the immutable bit.
Yes, yum could be modified to automatically unset the immutable bit, upgrade, and then re-set it. But there's an implicit understanding that normal programs *won't* play with the immutable bit (it's not there on all filesystems, and I understand Posix[1] doesn't specify it.[2])
In any case, having yum or rpm fiddle with the immutable bit prevents the sysadmin from saying "I know what I'm doing: RPM replaces this file on ugrade, and I Want It Staying Just As *I* Edited It, ----it!"
It's actually of some use as it is at the moment (as a way of over-riding the system tools). If it was treated the way you suggest, it would simply be a redundant way of expressing file permissions.
Hope this helps,
James.
[1] Posix is the IEEE standard defining Unix-like operating systems. In practice, not every Unix-like OS is Posix-compliant, nor is every de-facto standard a part of Posix. But deliberately using something that isn't in Posix is a good way to get non-portable programs.
[2] e.g. http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/files.html http://www.linuxsecurity.com/docs/LDP/Secure-Programs-HOWTO/files.html
On 11/29/05, James Wilkinson fedora@westexe.demon.co.uk wrote:
preeti malakar wrote:
Why is the immutable bit of all system binaries viz files in /sbin, /bin, /usr not set, so that none can change or delete them?
As Paul said, that would stop yum and rpm from upgrading those programs (say if the immutable binary has a security bug).
Also that would cause the prelink cronjob to fail...since it does intentionally modify files.
There's nothing of course to keep you from setting the immutable bit. And if you're building a super hardened system perhaps you should. It's just an extra layer beyond POSIX file permissions, mount options (mounting /usr read-only) and perhaps SELinux. But you must be prepared for things like rpm/yum or prelink to fail.
But I don't think this should be the default since it would confuse the heck out of most administrators, and scripts as well. -- Deron Meranda
Deron Meranda wrote:
On 11/29/05, James Wilkinson fedora@westexe.demon.co.uk wrote:
preeti malakar wrote:
Why is the immutable bit of all system binaries viz files in /sbin, /bin, /usr not set, so that none can change or delete them?
As Paul said, that would stop yum and rpm from upgrading those programs (say if the immutable binary has a security bug).
Also that would cause the prelink cronjob to fail...since it does intentionally modify files.
There's nothing of course to keep you from setting the immutable bit. And if you're building a super hardened system perhaps you
If you're that paranoid, a ro filesystem's hard to beat.
James Wilkinson wrote:
preeti malakar wrote:
Why is the immutable bit of all system binaries viz files in /sbin, /bin, /usr not set, so that none can change or delete them?
as you can see chattr /bin/login will give ------------- /bin/login
As Paul said, that would stop yum and rpm from upgrading those programs (say if the immutable binary has a security bug).
Most of them are owned by root: other users can't change them anyway, due to file permissions. And root has the ability to remove the immutable bit.
Yes, yum could be modified to automatically unset the immutable bit, upgrade, and then re-set it. But there's an implicit understanding that normal programs *won't* play with the immutable bit (it's not there on all filesystems, and I understand Posix[1] doesn't specify it.[2])
In any case, having yum or rpm fiddle with the immutable bit prevents the sysadmin from saying "I know what I'm doing: RPM replaces this file on ugrade, and I Want It Staying Just As *I* Edited It, ----it!"
Aa couple of times I've felt the urge to do that. Something was breaking /etc/resolve.conf and I couldn't discover what. chattr fixed that one.
Recently, on my WBEL server box something has been insistent that it absolutely _knows_ CUPS should only listen on 127.0.0.1. I think I've removed the offender, but chattr would certainly help there too.
other than that, I guess it would be pretty handy in a root kit:-)
--On Wednesday, November 30, 2005 10:47 AM +0800 John Summerfied debian@herakles.homelinux.org wrote:
Aa couple of times I've felt the urge to do that. Something was breaking /etc/resolve.conf and I couldn't discover what. chattr fixed that one.
I used the same solution, but I knew what it was: the DHCP client. It overwrites /etc/resolv.conf with the information from the DHCP server. And since it runs as root, it can overwrite a "read-only" file. The immutable bit stopped that.
Later I discovered that the DHCP client script will accept a setting in the interface config to ignore DNS information from the server.
On Tue, 2005-11-29 at 19:39 -0800, Kenneth Porter wrote:
I used the same solution, but I knew what it was: the DHCP client. It overwrites /etc/resolv.conf with the information from the DHCP server. And since it runs as root, it can overwrite a "read-only" file. The immutable bit stopped that.
Later I discovered that the DHCP client script will accept a setting in the interface config to ignore DNS information from the server.
As you discovered, you can configure the client to work in the way that you want. But this sounds like your server needs some tweaking.
--On Wednesday, November 30, 2005 10:17 PM +1030 Tim ignored_mailbox@yahoo.com.au wrote:
As you discovered, you can configure the client to work in the way that you want. But this sounds like your server needs some tweaking.
The issue was that I wanted to use a local caching name server, forwarding to the nameservers offered by the DHCP server. Ideally an updated named.conf would be written, not resolv.conf. But I decided to forgo forwarding and just make it use root hints. I had it secondary the local LAN's zone file so that it could resolve local names.
-
Deron Meranda -
James Wilkinson -
John Summerfield -
Kenneth Porter -
Paul Howarth -
preeti malakar -
Tim