Unfortunately there isn't an easy solution. This is because the passwd utility recreates the /etc/shadow file every time you change your password. Because of this, it will start on a different inode each time you use the passwd utility successfully.
For the system administrator, there is an easy work around. Start an LFS and use the passwd utility from within the LFS. If there are users that need to change their passwords, LDAP can provide an alternate means of client authentication that will allow users to change their passwords.
There is an option available that will allow users to change their system passwords when using the standard unix system filesUNIX authentication, but it's not recommended. /usr/bin/passwd can be given write access to /etc so it can always modify the shadow file regardless of it's inode number.
WARNING: If someone were to find a vulnerability in /usr/bin/passwd, or any of the libraries/PAM modules that it uses, he/she could potentially gain write access to your /etc directory. This defeats the purpose of using MAC in the first place since your access controls can now be circumvented if a vulnerability is found. Use this option at your own discretion!
If you are going to give /usr/bin/passwd write access to /etc, it is recommended that you create ACLs to protect every file and directory under /etc that you don't want /usr/bin/passwd to be able to modify. This will significantly reduce the risk (and possibly completely remove it if done correctly) mentioned above. For example:
/sbin/lidsconf -A -s /usr/bin/passwd -o /etc -j WRITE /sbin/lidsconf -A -s /usr/bin/passwd -o /etc/hosts.allow -j READONLY /sbin/lidsconf -A -s /usr/bin/passwd -o /etc/hosts.deny -j READONLY /sbin/lidsconf -A -s /usr/bin/passwd -o /etc/rc0.d -j READONLY /sbin/lidsconf -A -s /usr/bin/passwd -o /etc/rc1.d -j READONLY /sbin/lidsconf -A -s /usr/bin/passwd -o /etc/rc2.d -j READONLY /sbin/lidsconf -A -s /usr/bin/passwd -o /etc/rc3.d -j READONLY /sbin/lidsconf -A -s /usr/bin/passwd -o /etc/rc4.d -j READONLY /sbin/lidsconf -A -s /usr/bin/passwd -o /etc/rc5.d -j READONLY /sbin/lidsconf -A -s /usr/bin/passwd -o /etc/rc6.d -j READONLY /sbin/lidsconf -A -s /usr/bin/passwd -o /etc/init.d -j READONLY /sbin/lidsconf -A -s /usr/bin/passwd -o /etc/cron.d -j READONLY /sbin/lidsconf -A -s /usr/bin/passwd -o /etc/pam.d -j READONLY ... |
A note about updating inodes: If you have defined ACLs to grant access to /etc/shadow or /etc/passwd you must make sure to tell lids to update the inodes and then reload it's config files. Otherwise you may encounter problems.
For example: Assume /etc/passwd is protected as DENY, and /bin/login can read /etc/passwd. If the inodes aren't updated after changing a password, problems may arise the next time someone tries to log in. /bin/login won't be able to read /etc/passwd and you won't be able to log in, or worse yet, you will be able to login by just pressing the <ENTER> key.