[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Review: sect. 4.16.2 of the Securing Debian manual



On Thu, 13 Mar 2003, Alexander Reelsen wrote:

> > 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.

See below.

> > 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.

"Capabilities" is the next section that I plan to write/rewrite :-) The
interesting point about capabilities is that once one of them has been
removed, it can not be added back -- so lcap can only remove capabilities,
and not add them again. You can have a look at the current section 9.3.2.1
of the manual, there is a very short blurb on the subject (with some
references)

Does it answer your questions or did I miss a real loophole in the
strategy that I described ?

Frédéric



Reply to: