On Wednesday, October 19, 2005, at 02:29PM, LittleSnitch Support <[EMAIL PROTECTED]> wrote:
>> If it's public and the dev is willing I'd follow up on that off list. > >I can say that much: > >On the kernel level things are a bit different than on the user >(application) level - you can do things in the kernel that are >impossible to do in an application. > >LittleSnitch can not and will not protect itself against other kernel >extensions as installing and loading a kernel extension requires root >privileges (see point 3). > >Protecting the daemon (a user level process) against unauthorized >kills can be done on the kernel level - or better: Could be done in >10.3 and we hope to find a way again in 10.4 again. Understood, It's good to see the root/user privileges paradigm spelled out in reference to LS. And it's good to hear that you're looking for a way to protect it again. >Killing the daemon does not have to mean letting all network traffic >through. In the next minor release of LittleSnitch we will fix the >daemon kill issue. In the long run we will change the responsibility >assignment of the kernel extension, the daemon and the preference >pane. Then simply killing the daemon will _not_ "disable" LittleSnitch. Good again. Personally I'd like to see the changes such that kernel changes aren't required to protect the daemon. I bet you can guess that I'd like to see the daemon simply running as root. It won't be possible to take down the daemon from user space and the fewer modifications in kernel space the better. >On Oct 7, 2005, at 22:15, [EMAIL PROTECTED] wrote: >> I have tried SnitchCTL under 10.3 and indeed the daemon cannot be >> killed (at least not with the few commands I've tried - kill, kill >> -9, killall). But there's a glitch, first I don't find this >> behaviour normal, imho anything should be killable by root what if >> it's making a conflict with another app. > >The LittleSnitch Daemon can be terminated also in 10.3 if you do it >the way it's supposed to be: By simply going to the LittleSnitch >Preference Pane and clicking on the "Stop" button. If you try to kill >it by sending it kill signals from the Terminal.app LittleSnitch must >protect itself. > >On Oct 7, 2005, at 22:15, [EMAIL PROTECTED] wrote: >> Second thing is that it is easily defeated as unlike in 10.4, you >> can kill the kext (extension) which in turn will kill the daemon. > >There is no way of "killing" a kernel extension. You can _unload_ a >kernel extension - if you have root privileges. But once an attacker >has root privileges...see point 3 in the introduction.... That was a goof in writing as I know xSmurf meant kill in the context of unloading the extension. And you're right this does require root privileges. I think the bigger issue here is that unloading the kext in 10.4 results in a system crash. Whether it's a good idea or not, security wise, to unload the extension, LS shouldn't crash the system in this manner. >On Oct 10, 2005, at 3:10, [EMAIL PROTECTED] wrote: >> After building the proof of concept that SnitchCTL is I thought I >> should help the users who are scared because of the issues it >> brings up. This is why I came up with VeriSnitch: http:// >> snitchctl.smurfturf.net/index/verisnitch/ > >This is a good way to protect LittleSnitch until we fix this issue in >the next release. It's definitely better if such a tool comes from a >third party, because if it came with LittleSnitch, attackers would of >course simply kill the tool and then kill the LittleSnitch daemon. If >it comes form a third party chances are better that attackers do not >know about it. If you're extremely cautious you might want to rename >VeriSnitch after installation to some name an attacking program can't >guess. I'll say it's refreshing to see an approving response here. Many developers look at hacks like this as violations of their work. It's good to see a developer take this sort of thing as a security concern and respond with this level of feedback. >I hope I was able to answer your questions to your satisfaction. >Please let me know if you have any further questions. I'd say most questions have been addressed. I, and I'm sure the rest of the user base, look forward to the resulting security changes in the next version. That said I'll come back, briefly :), to the question that brought this subject up, the command line interface to LS. The first thread regarding this issue effectively ended with the line that a command line tool would be a security hazard (see: http://www.mail-archive.com/[email protected]/msg00262.html). In combination with what I've read just now, it seems clear that this isn't the case. >3. >There is no such thing as "100% security". We will protect >LittleSnitch from most kinds of attacks, but there are limits to >this. The definitive limit is a process attacking LittleSnitch which >has root privileges. A process with root privileges on a Unix system >can do _everything_ - once you managed to have a malicious process on >your system and it gains root privileges there is nothing it can't >do. One can make it cumbersome or a bit harder for this process but >one will not be able to stop it from doing what it's up to... Why could the command line tool not be run only as root? There are plenty of utilities installed with OS X that are intended to only be run as root or an administrator and the LS GUI requires authentication before configuration or stop/start. By setting the permissions of the command line utility properly the utility would only be able to be run by the root user. As you have said, it is impossible by design to secure a system against the root user, but this design relies on protection measures that should be beyond the worry of any application. The security at that level is in the trust given to administrators of a computer and the trust and knowledge of the user in running applications that request authentication. If the trust is broken by an application that requests authentication and abuses it by subverting LS or other security devices there is really nothing that can be done (as you say, see point 3). Additionally, the command line tool could be an installation option, disabled by default. Finally, a preference in the GUI configuration could allow/disallow configuration by the command line. As I've said before I can understand if a command line tool isn't at the front of the development schedule for any number of reasons (I'd like to hear those by the way :)), but the last response that it would be a security hole is somewhat baffling and I would like further comments on that. With that I think I've covered my concerns. Thanks again for the thorough response and updates on securing LS. I look forward to hearing more as the changes progress. And thanks again for LittleSnitch. -- -- arno s hautala /-\ [EMAIL PROTECTED] -- -- _______________________________________________ Littlesnitch-talk mailing list [email protected] http://at.obdev.at/mailman/listinfo/littlesnitch-talk
