From owner-freebsd-current@FreeBSD.ORG Fri Dec 11 05:47:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 945D81065676 for ; Fri, 11 Dec 2009 05:47:08 +0000 (UTC) (envelope-from pschmehl_lists@tx.rr.com) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.122]) by mx1.freebsd.org (Postfix) with ESMTP id 5B4D48FC15 for ; Fri, 11 Dec 2009 05:47:08 +0000 (UTC) Received: from [10.0.0.43] (really [76.184.157.127]) by cdptpa-omta01.mail.rr.com with ESMTP id <20091211043435979.UJGL5708@cdptpa-omta01.mail.rr.com>; Fri, 11 Dec 2009 04:34:35 +0000 Date: Thu, 10 Dec 2009 22:34:34 -0600 From: Paul Schmehl Message-ID: <1802D62A06A3A0AF64412A2C@Macintosh-2.local> In-Reply-To: <5d6848b00912101211m20c20995x212ac7e5093df42c@mail.gmail.com> References: <20091210144141.GB834@mech-cluster241.men.bris.ac.uk> <20091210095122.a164bf95.wmoran@potentialtech.com> <20091210162150.GA1135@mech-cluster241.men.bris.ac.uk> <5d6848b00912101211m20c20995x212ac7e5093df42c@mail.gmail.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Fri, 11 Dec 2009 12:18:31 +0000 Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Root exploit for FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Paul Schmehl List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 05:47:08 -0000 --On December 10, 2009 2:11:31 PM -0600 Kevin Wilcox wrote: > > 2009/12/10 Anton Shterenlikht : > >> I was just stressed after being forced by him >> to explain why I wanted firewall exceptions >> for two ports to my FreeBSD portscluster nodes. >> I explained the reasons and that was settled. > > Anton, I don't know about the UK, Great Britain or England, but in US > Universities, this is fairly common. It just serves as a sanity check > for the many, many requests central IT tends to get regarding allowing > ingress traffic for faculty/staff machines, and it gives the firewall > guys documentation that such-and-such machine should be receiving > inbound traffic on specific ports. I can confirm this, at least for us. Our practice is to only open ports for thoroughly justified business reasons, document thoroughly and audit regularly. > >> The Uni is, of course, >> addicted to Microsoft, but having realised all >> the problems with that, lately the policy has >> been to deny (!) MS users admin access to their >> own desktops. The situation is just ridiculous - >> if a MS user wants to install a piece of software >> on their PC he/she has to ask for permission, >> and then wait until some computer officer would >> come and do install for them. > > Again, I don't know about the UK, Great Britain or England, but in the > US this is also quite common, at least with regards to University > owned hardware. The first responsibility is to protect the network and > existing services. Sadly, many groups fail to provide the next step, > that being a relatively quick, easy way to have approved software > installed for users, and a method for having non-approved software > scrutinised and either approved or rejected. > This is less common at the universities that I'm familiar with. I think it becomes less common the larger and/or older a university is. The trend is to move in this direction, but we're also moving toward much stronger compliance controls. There are things about your computer's configuration and maintenance that you will no longer get to decide, regardless of the OS you run - password strength and length, for example, the ability to create local accounts, and other such things. These things aren't being done to harass or irritate users but because of long and bitter experience with a lack of controls. Our view is, if your computer is going to connect on our network it must be configured in certain ways and behave "normally" or you won't get a connection. >> Also recently, well.. about a year ago, no >> host (!) could be accessed from outside the >> Uni firewall. Special exception has to be >> obtained even for ssh. There is only one dedicated >> sun server which accepts only ssh. The users >> are supposed to dial to this frontend server >> first, and from there to hosts on the local net. > > Again, quite common. Most Universities here do not provide > public-facing IP addresses without some sort of application and > approval process. For example, we have a handful of machines that are > public facing but most of our hardware sits inside site-only networks. > To access those machines you either have to be on-campus or you have > to connect via VPN (and yes, we support Windows, Mac, Linux, Solaris, > *BSD). > This mirrors our practice. You don't get a public address without being thoroughly vetted *and* agreeing to the terms of use, unscheduled and unannounced monitoring and immediate disconnection without prior notice if a problem is detected. > Having an SSH proxy isn't an entirely bad idea, though I can see where > performance may be hindered. > >> I had to fight a long battle, well.. I had >> some support from other academics, to have >> a linux class in my Faculty. Here the >> opposition wasn't so much security, as >> "why would any undegraduate need linux", >> as if MS solutions are a pinnacle of human thought. > > That's a pretty fair question and one that I hope you would have asked > yourself before you made the push for the class. > >> And from I understand it's going to get worse. >> Apparently the IT services are drawing up >> plans to completely forbid use of "non-autorized" >> OS. I imagine fbsd will not be authorized. >> So I'm anticipating another battle already. > > Does this extend to computers used for academic research, student > owned computers being used on campus, etc? > > Perhaps it's because we're conditioned to think this way but a lot of > us at universities in the US see a lot of this as being commonplace > and to *not* do them is generally considered bad security practice. > This last part is surprising to me. Not only are we not Windows-centric, the very idea of not allowing a diversity of OSes is foreign to our operation. We are a heavy Solaris shop (as are many universities), have a good amount of Suse and RHEL and far less Windows servers exposed to the Internet. At the desktop users may install whatever they want, so long as it's maintained properly (which we audit routinely) and used in an acceptable manner (which you agree to when you get an account.) We have just about every OS you can imagine, including some you wouldn't believe still exist. I'm starting to wonder if the security manager really said what Anton claims he said, or Anton is filtering his perceptions through the anger he feels at being restricted in his ability to operate freely. If the latter is the case, you'd better adjust to it. It's the world of the future. You can do whatever you want at home, but on the corporate network you either follow the rules or lose your access. Paul Schmehl, If it isn't already obvious, my opinions are my own and not those of my employer. ****************************************** WARNING: Check the headers before replying