Re: Review: sect. 4.16.2 of the Securing Debian manual
Hi
On Thu, Mar 13, 2003 at 09:02:47PM +1100, Frederic Schutz wrote:
> <p> A better solution is to use the capabilities, as described in <ref
> id="proactive">. The capability of interest is called
> <tt>CAP_LINUX_IMMUTABLE</tt>: if you remove it from the capabilities
> bounding set (using for example the command <tt>lcap
> CAP_LINUX_IMMUTABLE</tt>) it won't be possible to change any 'a' or 'i'
> attribute on your system anymore, even by the superuser ! A complete
> strategy could be as follows:
>
> <enumlist>
> <item> Set the attributes 'a' and 'i' on any file you want;
> <item> Add the command <tt>lcap CAP_LINUX_IMMUTABLE</tt> to one of
> the startup scripts;
> <item> Set the 'i' attribute on this script and other startup files, as
> well as on the <prgn>lcap</prgn> binary itself;
> <item> Execute the above command manually (or reboot your system to
> make sure everything works as planned).
> </enumlist>
I always thought of CAP_LINUX_IMMUTABLE as a not-used extension. If you are
not root, you may have the capability to set files immutable or
append-only if it is given to you. If you are root (in your above
described scenario), you can switch on that capability everytime again,
or am I missing something obvious? At least in the above described way
this is possible, if you do not want to do that, you would need set
capabilities that way, that you cannot change them anymore.
> Now that the capability has been removed from the system, an intruder
> can not change any extended attribute on the protected files, and thus
> can not change or remove the files. If he forces the machine to reboot
> (which is the only way to restore the capabilities bounding set), it
> will easily be detected, and the capability will be removed again as
> soon as the system restarts anyway. The only way to change a
> protected file would be to boot the system in single-user mode or
> using another bootdisk, two operations that require physical access to
> the machine !
Are you sure on this one?
rwblinux2:~ # sysctl -A | grep cap-bound
kernel.cap-bound = -257
Being it a sysctl parameter makes me wonder whether you can set things
runtime (if you have the appropriate capability of course). lcap does
exactly that, writing in this procfile.
MfG/Regards, Alexander
--
Alexander Reelsen http://tretmine.org
ref@tretmine.org
Reply to: