> >> It works beautifully. As long as intruder does not know where exactly
> >> traps are placed he can not avoid traps. Will it work as long time defence
> >> against scilled cracker SPECIALLY directed against you ? Probably not.
> >> Will it stop most crackers ? For sure. As long as traps are NOT common and
> >> thus not known to majority of crackers!
>
> IP> Traps are common, as long as the intruder knows what he is looking for.
>
> Exactly. And if he is not ? Even VERY simple local traps will work against
> highly skilled intruder as long as he (she) not discover them (by reading
> code and just scanning system). And it'll requite LOTS of time.
Then you get a system that is full of traps, and they keep changing to
keep the bad guys out. Not really an option I think..
> IP> A very better idea is to secure programs, and avoid programs running as
> IP> root.
>
> In ideal world - yes. In real world it does not work: programs are created
> by humans and thus holes are inavoidable in programs of decent size.
I rather have a hole in my non-user running app then in some app that runs
as root..
> IP> BSDI also has a mode like this, the kernel secure levels. Basically means
> IP> that some operations are disabled, and the only was to switch the level is
> IP> from init 1 :-))
>
> So you just need to change code of init in memory via ptrace ? Not such a big
> problem...
Then you need to know exactly where it is.. In BSDI you can only read the
kernel memory, not write it in sec. level 2.
> IP> The 'main' risk if someone gets in that he replaces system bins.. So the
> IP> only way to detect this is a proper logging system, that cannot be
> IP> modified without someone noticing.
>
> It depends from system heavily. What about router where /sbin/init just set
> routing table and then just exit() ? Not very "normal" system but enough to
> get point...
> >> Hah. ONLY if he (she) will feel NEED to track "that style traces as well".
> >> See above.
>
> IP> Not wiping your traces degrades someone to script kiddie.
>
> Once. More. YOU. CAN. NOT. WIPE. TRACES. IF. YOU. DO. NOT. KNOW. WHERE. THEY.
> ARE. LOGGED.
You can always find out.. Logging is normally done through syslogd and
klogd.. Try to hide those..
> Yes, it does not work as long term defence. But it works and
> works GREAT as short term defence even against VERY skillfull cracker (the
> more skilled cracker is the less time he (she) will need to detect unusual
> tracking system but in many magabytes of code active in current systems even
> skilled cracker will need days to detect all places). Of course if code is
> in standard kernel with open sources he can do this all at home before
> starting attack so it's useless there.
Some weird modification is useless with Open Source. Everybody can just
read the code and write some nice detect app..
> IP> And I hate those..
>
> Becouse most damage was done by script kiddies ? Yes, they are not very skilled
> but there are A LOT OF them.
Their skill is not the problem.. The number is.
> >> > Nothing is safe agains an editor and someone who has root and know about
> >> > /dev/kmem
> >> >
> >> Again: if /dev/kmem is readable on system :-)
>
> IP> It is as root..
>
> In "Trusted XXX" (sometime in future "Trusted Linux" will be created) there
> are NO omnipotent root. Even in CURRENT linux you can disable ability to
> access hardware. Then EVERYONE (even root) will be unable to read /dev/kmem ...
>
> IP> And it it is not as root, what's the use of /dev/kmem ?
>
> Even if it's as root /dev/kmem can be not usable. Unfortunatelly currently
> X server will not work in such mode as well but not all systems out there
> need X server in first place...
Yep...
Igmar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:11 EST