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]
Review: sect. 4.16.2 of the Securing Debian manual
[please cc: me on replies]
Hi everyone,
I'm currently rewriting the section of the Securing Debian manual
concerned with the extended attributes of ext2/ext3. Before sending the
patch to Javier Fernández-Sanguino Peña I thought it may be worth asking
for comments here. It's far from being perfect, so if you have a few
minutes and want to have a look, any feedback is welcome -- technical or
grammatical, anything.
Thanks in advance !
Frédéric
The ext2 file system extended attributes (chattr/lsattr)
In addition to the usual Unix permissions, the ext2 and ext3
filesystems offer a set of extended attributes that give you more
control over the files on your system. Unlike the basic permissions,
these attribute are not displayed by the usual ls -l
command or changed using chmod, and you need two other
utilities, lsattr and chattr (in package
e2fsprogs) to manage them. Note that this means
that extended attributes will usually not be saved when you backup
your system, so if you change any of these attributes, it may be worth
saving the successive chattr commands in a script so that
you can set them again later if you have to restore a backup.
Among the extended attributes available, the two that are most
important for increasing security are referenced by the letters 'a'
and 'i', and they can only be set (or removed) by the superuser:
The 'a' attribute ('append'): a file with this attribute can only be
opened for writing in append mode, which means that you can still add
more content to it but it is impossible to modify previous
content. This attribute is especially useful for the log files stored
in /var/log/, though you should consider that they get
moved sometimes due to the log rotation scripts.
The 'i' attribute ('immutable'): a file with this attribute can
neither be modified nor deleted or renamed and no link can be created
to it, even by the superuser.
It is easy to see how the 'a' attribute improves security, by giving
to programs that are not running as the superuser the ability to add
data to a file without modifying its previous content. On the other
hand, the 'i' attribute seems less interesting: after all, the
superuser can already use the basic Unix permissions to restrict
access to a file, and an intruder that would get access to the
superuser account could always use the chattr program to
remove the attribute. Such an intruder may first be confused when he sees
that he is not able to remove a file, but you should not assume that
he is blind - after all, he got into your system !
An easy (but very insecure !) way to improve this situation would be
to remove the chattr and lsattr programs
from the system after setting the attributes on files you want to
protectNote that you can not simply remove the package
e2fsprogs because it is of priority
Required. You can however safely delete the two binary files
as long as you have a copy on a removable media along with their MD5
fingerprints.. This would give you some more time to detect
the intrusion, since the intruder would have to download (and maybe
compile) his own copy of the binaries on your system, but it still
falls short of a secure solution.
A better solution is to use the capabilities, as described in . 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).
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 !
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]
Review: sect. 4.16.2 of the Securing Debian manual
[please cc: me on replies]
Hi everyone,
I'm currently rewriting the section of the Securing Debian manual
concerned with the extended attributes of ext2/ext3. Before sending the
patch to Javier Fernández-Sanguino Peña I thought it may be worth asking
for comments here. It's far from being perfect, so if you have a few
minutes and want to have a look, any feedback is welcome -- technical or
grammatical, anything.
Thanks in advance !
Frédéric
The ext2 file system extended attributes (chattr/lsattr)
In addition to the usual Unix permissions, the ext2 and ext3
filesystems offer a set of extended attributes that give you more
control over the files on your system. Unlike the basic permissions,
these attribute are not displayed by the usual ls -l
command or changed using chmod, and you need two other
utilities, lsattr and chattr (in package
e2fsprogs) to manage them. Note that this means
that extended attributes will usually not be saved when you backup
your system, so if you change any of these attributes, it may be worth
saving the successive chattr commands in a script so that
you can set them again later if you have to restore a backup.
Among the extended attributes available, the two that are most
important for increasing security are referenced by the letters 'a'
and 'i', and they can only be set (or removed) by the superuser:
The 'a' attribute ('append'): a file with this attribute can only be
opened for writing in append mode, which means that you can still add
more content to it but it is impossible to modify previous
content. This attribute is especially useful for the log files stored
in /var/log/, though you should consider that they get
moved sometimes due to the log rotation scripts.
The 'i' attribute ('immutable'): a file with this attribute can
neither be modified nor deleted or renamed and no link can be created
to it, even by the superuser.
It is easy to see how the 'a' attribute improves security, by giving
to programs that are not running as the superuser the ability to add
data to a file without modifying its previous content. On the other
hand, the 'i' attribute seems less interesting: after all, the
superuser can already use the basic Unix permissions to restrict
access to a file, and an intruder that would get access to the
superuser account could always use the chattr program to
remove the attribute. Such an intruder may first be confused when he sees
that he is not able to remove a file, but you should not assume that
he is blind - after all, he got into your system !
An easy (but very insecure !) way to improve this situation would be
to remove the chattr and lsattr programs
from the system after setting the attributes on files you want to
protectNote that you can not simply remove the package
e2fsprogs because it is of priority
Required. You can however safely delete the two binary files
as long as you have a copy on a removable media along with their MD5
fingerprints.. This would give you some more time to detect
the intrusion, since the intruder would have to download (and maybe
compile) his own copy of the binaries on your system, but it still
falls short of a secure solution.
A better solution is to use the capabilities, as described in . 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).
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 !
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
