Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What is the effect of setting immutable bit on /boot partition with perspective of security. is it advisable to set the immutable bit (-i) to everything under /boot? Will it enhance or degrade the system security?

I would like to go further and do the same for other "precious" files like /etc/bind/named.conf, etc.

share|improve this question

closed as unclear what you're asking by Michael Kjörling, slm, Anthon, rahmu, Renan Aug 24 '13 at 14:30

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question.If this question can be reworded to fit the rules in the help center, please edit the question.

The usual approach to a immutable (of sorts) /boot is to not even mount it. You can't modify it unless you do... – frostschutz Aug 24 '13 at 10:09
9 Upvotes and Acceptance to answer shows that Question is just CRYSTAL CLEAR. – Nishan Aug 28 '13 at 7:33
up vote 11 down vote accepted


Don't do this unless you have peculiar auditing requirements. It's generally more trouble than it's worth.


The only account that should have write access to /boot is root. If you have root, you can unset immutable bits and pretty much do what you want anyway.

The major downside of mounting /boot read-only, setting immutable bits, or anything similar is that you will need to undo those settings every time you update your kernel or boot loader. This is much more likely to trip you up than it is to offer meaningful security.


Depending on what you're really trying to do, you may have some alternatives. For example:

  1. Ensuring that /boot is on a separate partition that is rarely written to is a good idea if you're worried about filesystem corruption.
  2. Periodically validating the contents of /boot with Tripwire or debsums, especially when comparing against hashes stored on separate read-only media, is a good security measure if you're worried about tampering.
  3. Mounting /boot read-only, and then having your package manager mount it read-write during updates, may be useful.

Remounting Read-Only Partitions During Apt Updates

As an example the last alternative, you might configure /boot read-only in your /etc/fstab, then add something similar to the following to your /etc/apt/apt.conf on Debian-based systems:

DPkg {
    Pre-Invoke { "mount -o remount,rw /boot"; };
    Post-Invoke {
        "test ${NO_APT_REMOUNT:-no} = yes ||
        mount -o remount,ro /boot ||

This will keep /boot read-only except during updates. Obviously, you will need to do something different if you aren't using the apt package manager, or if the above doesn't work for some other reason.

share|improve this answer
As long as you don't use distro kernels you can control the access to /boot fairly well and its not really tripping either. I don't know about immutable bits, but I like to mount /boot ro, b/c it greatly lowers the chance for fs corruption if there is any fault. I also keep a minimal ramdisk linux in there, so that I can recover quickly if stuff hits the fan. – Bananguin Aug 24 '13 at 15:45

Not the answer you're looking for? Browse other questions tagged or ask your own question.