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

Re: Followup: Syslog



On Sat, Apr 14, 2001 at 02:58:02PM +0200, Luca Gibelli wrote:
> > One additional tweak which falls into line with the security setups, that I
> > think is a good idea is to made the log files in /var/log to be chattr +a
> > (append only) so logfiles cannot be modified or removed altogether to cover
> > up tracks. This isn't the the biggest security trick because all it does is
> > make it if you don't know about chattr then you can't install a trojan. If
> 
> It's indeed *too* trivial.

though a large number of script kiddies are really really dumb.

> I'd suggest using LIDS for such things.
> For those who don't know it, it's a kernel patch which adds capabilities
> support. It makes impossible to delete logs 'cause in order to disable
> "append only" you should reboot with a kernel without lids, but lids forbids
> rebooting unless the admin is logged from a local console.

or just use lcap

lcap CAP_SYS_MODULE CAP_SYS_RAWIO CAP_SYS_BOOT CAP_LINUX_IMMUTABLE

that revokes the ability to load modules, denies access to /dev/mem,
/dev/kmem and /proc/kcore.  revokes the ability to reboot(), and
revokes the ability to set or remove immutable/append only bits.  

there are a few problems with this:

throw away your logrotation scripts, they will now fail and your logs
will permanently bloat until you reboot the system into single user
mode and rotate them on the console manually.  

you can't reboot remotely anymore, a shutdown -r now will bring the
system all the way down to where it runs the actual reboot command
which will fail and init will spawn sulogin.  

there is no way to seal the raw disk devices using linux capabilities,
so the immutability bits can be trivially removed by directly
modifying the filesystem through /dev/hda* or /dev/sda*.  this is a
pretty lame oversight IMO given the BSD securelevel at level 1 revokes
the ability to access raw devices for mounted filesystems, and at
level 2 revokes the ability to access any raw disk device.  

you need to protect the script running lcap at boot, this means you
have to make / or /etc immutable which will severely break your
system (i have read an immutable / makes the system unusable)
otherwise all the cracker needs to do is:

cp -a /etc /etc.foo
mv /etc /etc.crap
mv /etc.foo /etc
<remove annoying lcap script>
reboot

of course that last step is liable to make someone notice, and if you
revoked CAP_SYS_BOOT your machine will just go down and stay down
until you take care of it and hopefully notice the bogus /etc.crap.
(which can't be rm -rfed until after the reboot && chattr -R -ia
/etc.crap)

lids might be able to solve some of these problems, but remains a
royally obnoxious thing to administer, you end up having to do pretty
much everything from the console (depending on the config i suppose),
and well if i wanted that i would use NT ;-)

and it sounds like lids may not be portable to arch != i386.

-- 
Ethan Benson
http://www.alaska.net/~erbenson/

Attachment: pgpLqJB4zLg1m.pgp
Description: PGP signature


Reply to: