Results 1 to 10 of 112

Thread: TuxGuardian - application based firewall

Threaded View

  1. #21
    Join Date
    Jun 2011
    Atlanta Georgia
    Ubuntu 10.04 Lucid Lynx

    Re: TuxGuardian - application based firewall

    Quote Originally Posted by scruffyeagle View Post
    I just finished carefully reading every single post in this thread, and have a couple of things to say:

    *) Using the term "Windows mindset" or repeating "this isn't Windows" is a cop out - a way of avoiding discussing the details, by lumping dissenting voices into a generic stereotyping.

    *) Phone home software in drivers IS an issue, and it's unavoidable. It has absolutely no connection with questions re. repositories vs. other sources. It's the consequence of equipment manufacturers working hard to dig deeper into the pockets of their customers, and working hard to leverage their sales/transactions into further profit regardless of the ethics of their methods. Use of those drivers is a necessity; the equipment is designed from scratch to insist on it. This problem won't go away just because this is Linux, and the time-honored traditional methods & tools in Linux are insufficient to obstructing this new threat to privacy. Therefore, new tools & methods are required.

    Based on what I've read in this thread, process #'s are insufficient for this task, as are port #'s. The problem in limiting outgoing connections on a per-application basis, is that the Linux environment doesn't maintain a comprehensive table of program I.D. #'s. (Please correct me, if I'm wrong about that.) In the absence of a comprehensive table of program I.D. #'s, it's not possible to maintain a table of which programs own which current connections - or, to block programs from making connections. Such a table of program I.D. #'s would have to be updated & maintained during every instance of program installation, including assigning separate I.D. #'s for each & every driver. Given such a table to reference, it would be easy to implement per-program internet access privileges. The registration table would have 3 columns: Text of program name, numeric program I.D. # assigned at installation time, and numeric value indicating privileges.

    If such a table existed, then establishing a connection could be allowed or refused based on the value of the privileges info in the table. A request for an outgoing connection would require the requesting program to provide a valid I.D. #. Administrators would be able to review &/or edit the privileges in the table on an as-needed basis. A session log would be maintained of programs owning current outgoing connections, with start & end times. The drawback to this framework, is the possibility of programs accessing the table's values for the purpose of spoofing I.D. #'s & associated privileges. I'm not proposing that this would be a replacement for IPtables - it would be an associated accesory, plugging a gap in the security measures.

    I don't know the details of operation, re. TuxGuardian, so I don't know if it does what I've proposed here. All I'm really sure of, is that software to do what I've written in the previous 2 paragraphs is needed.

    But, please don't tell me that if I want such a feature in the OS then I should write it myself. My programming activities were limited to BASIC - however, my experience in flowcharting, principles of program design, and complex systems analysis are still valid & useful. Of course, if you think it would be right & proper for the entire Linux community to wait until I somehow manage to master writing software in a new language like C++ or Python...?

    To sum up: A new problem exists, and traditional methods are insufficient for dealing with it. A method for controlling this problem exists - all that's required is for the community of Linux developers to recognize & acknowledge the problem, then create software that applies the remedy.

    First iptables is not now nor has it EVER been an application firewall. If you want application based firewalling and containment you need to check out things like SELinux or Apparmor, many applications have their own application (for instance mod-security) for Apache.

    As far as applications becoming a server or creating connections -- there are methods around this without reinventing the wheel. Iptables can and does provide the functionality to prevent this. Granted -- this is not in the default UFW configuration, that does not mean it does not exist.

    For Windows mindset I think that might be the case here : it seems like you are looking for something like Zone Alarm to pop up a warning that something is trying to access the network. While there may be front ends for this, Linux largely assumes you know what you are doing -- and most Linux users find functionality like this inconvenient to say the least.

    When it comes to pid's and connection tracking, again the functionality is there (not in default configuration) , and in my opinion regardless of the platform, and regardless of the method of controlling it application inventories have ALWAYS been a personal responsibility. While creating an application to automate this task might be beneficial to some I doubt it. The reason being, most users who would need something like this are "clickers" they click yes to everything, with the hopes that whatever task they are trying to complete is successful.

    Bottom line , I think there is quite enough of this functionality for users who really want it. While it is there it remains un-intrusive for those who do not wish to deal with an operating system that looks and feels like Windows.

    As far as writing your own functionality -- if you want a niche application request filled you may have to pony up and write it for yourself. When writing something like an operating system you have a very wide and diverse range of needs and wants. You can't meet them all. So it's not unreasonable to say if you want something that the majority doesn't want go ahead and learn C and create it.
    Last edited by Dangertux; August 25th, 2011 at 05:20 PM.

Tags for this Thread


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts