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."
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
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?"
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."
1) Beer.
2) Cops (on TV)
3) Food. p All I need on a Saturday evening.
Yet, here you are, posting on Slashdot
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.
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
"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.
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?
** I realise this is following an offtopic post, however I also feel its worth discussing & debunking **
And what do you suggest we use?
C is powerfull, fast, and well known. The advantages are clear, and buffer overflows are the product of poor coding, where a coder misuses memory, and lapses to forget that all input is infact, quite evil.
The very concept of secure computing is a very new one. Yes, 20 years ago, Buffer Overflows were possible, however 20 years ago, we werent worrying about them, becuase simply put it was not an issue. With the advent of network computing in the last 10 years, it has slowly become an issue, and since then, any coder worth his money has learnt to deal with them, to assume that input is evil, to ensure that his code cannot be subjected to remote exploitation.
Other languages, have their place, however for mere speed of execution, and its powerfull nature, C/C++ is not challenged. The only challenge that needs to be conquered is to ensure that programmers think through what they are doing, before they do it.
#!/bin/csh cat $0
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 !