Re: Review: sect. 4.16.2 of the Securing Debian manual
Note that you must also prevent raw disk access by the superuser as well. If I were securing a system, I think I'd opt for offline storage of logs (line printer, serial line, WORM/CDR driver, write-only network logging to a "secure" machine.) Trying to protect the local system from the superuser is a rotten battle to fight. Better to avoid it to begin with, because you will probably lose. (It only takes one hole that you miss. And disabling superuser functionality would probably cause more suffering then any possible benefit.) This might change once we have hardware support for "protected applications". (depending on how the TCPA stuff falls out and assuming mere mortals get access to such controls). Regards, Adam On Thu, 2003-03-13 at 22:41, Peter Cordes wrote: > On Thu, Mar 13, 2003 at 10:22:19PM +1100, Frederic Schutz wrote: > > Does it answer your questions or did I miss a real loophole in the > > strategy that I described ? > > If an attacker gets root and loads a kernel module, that module could > restore the immutable capability. You'd have to disable loadable modules > for that to be bulletproof. (unless the commonly used rootkits already do > this, it would slow down an attacker and cause them to make more noise.)
Re: Review: sect. 4.16.2 of the Securing Debian manual
Note that you must also prevent raw disk access by the superuser as well. If I were securing a system, I think I'd opt for offline storage of logs (line printer, serial line, WORM/CDR driver, write-only network logging to a "secure" machine.) Trying to protect the local system from the superuser is a rotten battle to fight. Better to avoid it to begin with, because you will probably lose. (It only takes one hole that you miss. And disabling superuser functionality would probably cause more suffering then any possible benefit.) This might change once we have hardware support for "protected applications". (depending on how the TCPA stuff falls out and assuming mere mortals get access to such controls). Regards, Adam On Thu, 2003-03-13 at 22:41, Peter Cordes wrote: > On Thu, Mar 13, 2003 at 10:22:19PM +1100, Frederic Schutz wrote: > > Does it answer your questions or did I miss a real loophole in the > > strategy that I described ? > > If an attacker gets root and loads a kernel module, that module could > restore the immutable capability. You'd have to disable loadable modules > for that to be bulletproof. (unless the commonly used rootkits already do > this, it would slow down an attacker and cause them to make more noise.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Review: sect. 4.16.2 of the Securing Debian manual
I currently spend a lot of time hardening boxes, is this discussion based on the released doc I can get off the debian web site? or a new draft? Steven -Original Message- From: Peter Cordes [mailto:[EMAIL PROTECTED] Sent: Friday, 14 March 2003 7:41 To: debian-security@lists.debian.org Subject: Re: Review: sect. 4.16.2 of the Securing Debian manual On Thu, Mar 13, 2003 at 10:22:19PM +1100, Frederic Schutz wrote: > Does it answer your questions or did I miss a real loophole in the > strategy that I described ? If an attacker gets root and loads a kernel module, that module could restore the immutable capability. You'd have to disable loadable modules for that to be bulletproof. (unless the commonly used rootkits already do this, it would slow down an attacker and cause them to make more noise.) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Review: sect. 4.16.2 of the Securing Debian manual
On Thu, Mar 13, 2003 at 10:22:19PM +1100, Frederic Schutz wrote: > Does it answer your questions or did I miss a real loophole in the > strategy that I described ? If an attacker gets root and loads a kernel module, that module could restore the immutable capability. You'd have to disable loadable modules for that to be bulletproof. (unless the commonly used rootkits already do this, it would slow down an attacker and cause them to make more noise.) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
RE: Review: sect. 4.16.2 of the Securing Debian manual
I currently spend a lot of time hardening boxes, is this discussion based on the released doc I can get off the debian web site? or a new draft? Steven -Original Message- From: Peter Cordes [mailto:[EMAIL PROTECTED] Sent: Friday, 14 March 2003 7:41 To: [EMAIL PROTECTED] Subject: Re: Review: sect. 4.16.2 of the Securing Debian manual On Thu, Mar 13, 2003 at 10:22:19PM +1100, Frederic Schutz wrote: > Does it answer your questions or did I miss a real loophole in the > strategy that I described ? If an attacker gets root and loads a kernel module, that module could restore the immutable capability. You'd have to disable loadable modules for that to be bulletproof. (unless the commonly used rootkits already do this, it would slow down an attacker and cause them to make more noise.) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Review: sect. 4.16.2 of the Securing Debian manual
On Thu, Mar 13, 2003 at 10:22:19PM +1100, Frederic Schutz wrote: > Does it answer your questions or did I miss a real loophole in the > strategy that I described ? If an attacker gets root and loads a kernel module, that module could restore the immutable capability. You'd have to disable loadable modules for that to be bulletproof. (unless the commonly used rootkits already do this, it would slow down an attacker and cause them to make more noise.) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Review: sect. 4.16.2 of the Securing Debian manual
On Thu, 13 Mar 2003 12:21:44 +0100 Alexander Reelsen wrote: >> "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) >Ok. I wasn't sure anymore, whether it is completely impossible to add back >a capability. Do you have some reference about that? I have something in >mind about that but I can't remember exactly. See answer above, some references are already provided in the manual. I'll add some more when I'll rewrite the capabilities section. Actually, I wouldn't swear that it is _completely_ impossible to add back a capability, but noone seems to consider that this is feasible (or maybe noone cares ? capabilities haven't really been used much) Frédéric
Re: Review: sect. 4.16.2 of the Securing Debian manual
On Thu, 13 Mar 2003 12:21:44 +0100 Alexander Reelsen wrote: >> "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) >Ok. I wasn't sure anymore, whether it is completely impossible to add back >a capability. Do you have some reference about that? I have something in >mind about that but I can't remember exactly. See answer above, some references are already provided in the manual. I'll add some more when I'll rewrite the capabilities section. Actually, I wouldn't swear that it is _completely_ impossible to add back a capability, but noone seems to consider that this is feasible (or maybe noone cares ? capabilities haven't really been used much) Frédéric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Review: sect. 4.16.2 of the Securing Debian manual
Hi On Thu, Mar 13, 2003 at 10:22:19PM +1100, Frederic Schutz wrote: > On Thu, 13 Mar 2003, Alexander Reelsen wrote: > > Are you sure on this one? > > > > # 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) Ok. I wasn't sure anymore, whether it is completely impossible to add back a capability. Do you have some reference about that? I have something in mind about that but I can't remember exactly. > Does it answer your questions or did I miss a real loophole in the > strategy that I described ? If you provide some reference, then for sure :) MfG/Regards, Alexander -- Alexander Reelsen http://tretmine.org [EMAIL PROTECTED]
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: > > > > > >Set the attributes 'a' and 'i' on any file you want; > >Add the command lcap CAP_LINUX_IMMUTABLE to one of > > the startup scripts; > >Set the 'i' attribute on this script and other startup files, as > > well as on the lcap binary itself; > >Execute the above command manually (or reboot your system to > > make sure everything works as planned). > > > 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
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: > A better solution is to use the capabilities, as described in id="proactive">. The capability of interest is called > CAP_LINUX_IMMUTABLE: if you remove it from the capabilities > bounding set (using for example the command lcap > CAP_LINUX_IMMUTABLE) 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: > > >Set the attributes 'a' and 'i' on any file you want; >Add the command lcap CAP_LINUX_IMMUTABLE to one of > the startup scripts; >Set the 'i' attribute on this script and other startup files, as > well as on the lcap binary itself; >Execute the above command manually (or reboot your system to > make sure everything works as planned). > 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 [EMAIL PROTECTED]
Re: Review: sect. 4.16.2 of the Securing Debian manual
Hi On Thu, Mar 13, 2003 at 10:22:19PM +1100, Frederic Schutz wrote: > On Thu, 13 Mar 2003, Alexander Reelsen wrote: > > Are you sure on this one? > > > > # 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) Ok. I wasn't sure anymore, whether it is completely impossible to add back a capability. Do you have some reference about that? I have something in mind about that but I can't remember exactly. > Does it answer your questions or did I miss a real loophole in the > strategy that I described ? If you provide some reference, then for sure :) MfG/Regards, Alexander -- Alexander Reelsen http://tretmine.org [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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: > > > > > >Set the attributes 'a' and 'i' on any file you want; > >Add the command lcap CAP_LINUX_IMMUTABLE to one of > > the startup scripts; > >Set the 'i' attribute on this script and other startup files, as > > well as on the lcap binary itself; > >Execute the above command manually (or reboot your system to > > make sure everything works as planned). > > > 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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: > A better solution is to use the capabilities, as described in id="proactive">. The capability of interest is called > CAP_LINUX_IMMUTABLE: if you remove it from the capabilities > bounding set (using for example the command lcap > CAP_LINUX_IMMUTABLE) 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: > > >Set the attributes 'a' and 'i' on any file you want; >Add the command lcap CAP_LINUX_IMMUTABLE to one of > the startup scripts; >Set the 'i' attribute on this script and other startup files, as > well as on the lcap binary itself; >Execute the above command manually (or reboot your system to > make sure everything works as planned). > 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 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
