Slashdot Mirror
Sebek2 - A Kernel-based Data Capture Tool
LogError writes "Sebek is a piece of code the lives entirely in kernel space and records either some or all data accessed by users on the system. This paper is a detailed discussion of Sebek, how it works and its value."
Great, now we can have goatse.cx links in kernel panic messages...
All those people running SELinux might want to reconsider when the next release includes a kernel patched with this. To combat terrorism, of course!
You can mod your friends, you can mod your nose, but you can't mod your friend's nose.
This can just as easily be modified and used by blackhats as an advanced rootkit, though. Like everything, it's a double-edged sword.
Why not just merge SELinux with Linux? Does the NSA step outside copyright law to prevent this, or has no one bothered to do the necessary work?
You can't judge a book by the way it wears its hair.
Sounds Vulcan.
I'm sure the speed of a kernel-level logger will be amazing. I bet WinXP comes with one already running and recording everything.
Actually, doesn't Windows come with some pretty fancy-schmancy documented (and undocumented) kernel-level logging APIs?
Or is this *nix? I should RTFA.
Wer mit Ungeheuern kämpft, mag zusehn, dass er nicht dabei zum Ungeheuer wird. --Nietzsche
I did that all last week.
Umm... whats your excuse?
After all, with the Gen2 honeynets out there, this is the tool of choice.
This tool has been out at honeynet.org for months now.I've been using it for at least 2 months.
THIS IS NOT NEWS,
Mirrored here: Sebek.pdf
-----
I never heard of honeynet. I didn't know I could run a kernel level logger on my firewall. Maybe someone at /. turned the story down two months ago, but I never heard of this. So why didn't you send in the story when it was "news?"
How many of you clicked on the link and saw just two paragraphs of nothing? At least nothing that would allow you to come up with your own conclusion?
There is no spoon or sig.
If I remember right, one component dealt with keycodes being replaced with encrypted and digitally signed packets that could only be decoded by the process authenticated by the palladium hardware.
Any spyware, even in the kernel couldn't get the key to decrypt these packets.
If this is right, and if anyone remembers the details, please help fill me in. No doubt, dozens or hundreds will correct me if I'm wrong. :-)
I couldn't see it mentioned anywhere, but I found this on www.kemet.org, a site about the religious tradition of Ancient Egypt:
Sebek (Sobek; G/R Suchos) - "Watching over You" Son of Nit (and also, according to some myths, Set), Sebek is either depicted as a full crocodile, or, less often, as a crocodile-headed man. He is often given the epithets of Heru-sa-Aset as a Netjer [manifestation of god] of protection, healing and vengeance over the wrongdoer. In some mythologies Sebek is a powerful and awe-inspiring denizen of the underworld, and was invoked to do away with annoyances and negative situations, in the phrase "to Sebek with it(him)!," much as modern-day slang consigns bothersome things and persons "to Hell."
this article is interesting. I'm not an admin of a corporate wan and there's only so much damage that can be done to a home network, so my interest is not sufficient to compel me to "search for it" anymore than my interest in particle physics would drive me to "search for" the latest technical papers on particel accelerators.
If this offends your l33t sensibilities then you need a thorough ass kicking by RMS and JP Barlow to remind you of why sites like slashdot even exist.
This type of kernal-level tap on the flow of commands/data for a high-level entity is perfect for advanced knowledge management applications. Rather than create a KM application that is compatible with various web & office applications, we could tap into what those applications are doing by watching their calls to the kernal and core libraries.
What I want is something that lets me monitor all the calls to string-related objects (Sebak only seems to watch calls to read() ). Processing all of an application's uses of strings might be data overload, but disk space is cheap, so who cares.
Two wrongs don't make a right, but three lefts do.
But unfortunately we don't seem to have made that much progress, despite the reasonably large number of development tools we have that address such issues (including anything from memory debuggers to string libraries). I mean, really ... people are still writing these things in C ... in the 21st century! I'm a big fan of picking the right tool for the job, but I think it should be clear by now that C isn't the right tool for writing secure software. There are simply too many ways to screw up.
I think it's time we started writing system software (that is, software which provides services but which runs as a process under the OS) in a language which doesn't have these problems. And if a suitable language is unavailable, that argues strongly for creating that language.
You might still have to worry about buffer overflow exploits against the kernel, but that's a much more manageable problem.
Does this mean you do setup with a vulcan mind meld, and close the program with a neck pinch?
*There's Klingons on the starboard bow, scrape em off Jim!*
the article summary mentions that it is the bastard child of existing kernel modding rootkits.
So, uh, they already have this. But I doubt they'll put them up on freshmeat...
Fuck Beta. Fuck Dice
The package was allready defeated by the Bad Guys.
<A HREF="http://www.phrack.nl/phrack62/p62-0x07.txt"
<i>Note: This is not done by the Offical Phrack Group</i>
"If SELinux merges with Linux, them I'm off to BSD, or somewhere where big brother is not."
;)
That was a really dumb statement.
SELinux is merging with Linux, but it is an optional component, like ALSA or a NIC driver. It's a tool, and a useful one. Get over it.
BTW, FreeBSD (arguably the most advanced BSD) already has a very similar framework, the "TrustedBSD Mandatory Access Control Framework." It does similar things as SELinux, and in fact has an optional port of the SELinux stuff in development. (I for one can't wait for it
SELinux and TrustedBSD are good things, and are also entirely optional. Get with the program.
Guess what? You are an idiot, just as the creator of the parent post is an idiot. You have no idea what exactly SELinux or the like actually do, nor the inclination to find out before you say such rediculous things.
Unlike Microsoft's Palladium which is about them maintaining their control over people, SELinux, TrustedBSD and the TCPA are about security of one's own machines or networks.
or can't one simply modify the shell that the attacker is using to have it log the keystrokes either as it receives them from sshd, or before they're sent to ssh and encrypted?
Not to mention that I'm sure people like Linus would be sure any code of SELinux is gone over with a fine -toothed comb before being folded into the official kernel.
Ahh, baseless paranoia, yay!
if SElinux is being ported to BSD, why not to port TrustedBSD to Linux? Just to keep the balance and the choice :)
Less is more !