From owner-freebsd-security@FreeBSD.ORG Mon Sep 19 10:27:09 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D4AE16A41F for ; Mon, 19 Sep 2005 10:27:09 +0000 (GMT) (envelope-from cfp@ruxcon.org.au) Received: from ruxcon.org.au (mail.ruxcon.org.au [209.9.226.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0100443D46 for ; Mon, 19 Sep 2005 10:27:08 +0000 (GMT) (envelope-from cfp@ruxcon.org.au) Received: by ruxcon.org.au (Postfix, from userid 1005) id B7EC71AD4004; Mon, 19 Sep 2005 10:27:07 +0000 (UTC) Date: Mon, 19 Sep 2005 10:27:07 +0000 To: undisclosed-recipients: ; Message-ID: <20050919102707.GA6779@ruxcon.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i From: cfp@ruxcon.org.au (RUXCON Call for Papers) X-Mailman-Approved-At: Mon, 19 Sep 2005 11:33:46 +0000 Subject: RUXCON 2005 Update X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2005 10:27:09 -0000 Hi, RUXCON is quickly approaching yet again. This e-mail is to bring you up to date on the latest developments on this years conference. Our speakers list is complete [1] and our timetable has been finalised [2]. Below is a list of presentations for RUXCON 2005 (in order of acceptance): 1. Breaking Mac OSX - Ilja Van Sprundel & Neil Archibald 2. Binary protection schemes - Andrew Griffiths 3. Using OWASP Guide 2.0 for Deep Penetration Testing - Andrew van der Stock 4. Black Box Web Application Penetration Testing - David Jorm 5. Long Filename, Long Parameter, Malformed Data. Another Day, Another Vulnerability. Same Bug, Different App. - Brett Moore 6. Computer Forensics: Practise and Procedure - Adam Daniel 7. Poker Paranoia - Sean Burford 8. Moving towards the Artificial Hacker - Ashley Fox 9. Attack automation - Roelof Temmingh 10. Electronic Evidence - a Law Enforcement Perspective - Jason Beckett 11. Beyond NX: An attackers guide to anti-exploitation technology for Windows - Ben Nagy 12. Crypto Rodeo - Amy Beth Corman 13. Trust Transience: Post Intrusion SSH Hijacking - Metlstorm 14. Attacking WiFi with traffic injection - Cedric "Sid" Blanche 15. Securing Modern Web Applications - Nik Cubrilovic 16. Malware Analysis - Nicolas Brulez 17. Deaf, Dumb and Mute: Defeating Network Intrusion Detection Systems (NIDS) - Christian Heinrich As in previous years, there will be activities and competitions, which allow attendees to have fun, win prizes, and socialise, all while enjoying a cold beer on an Australian summers day. Some activities which will be held during the conference include: * Capture the flag * Reverse engineering * Exploit development * Chilli eatoff * Trivia This will be the third year in a row in which we've brought a quality conference to the Australian computer security community. Hope to see you there. Regards, RUXCON Staff http://www.ruxcon.org.au [1] http://www.ruxcon.org.au/2005-presentations.shtml [2] http://www.ruxcon.org.au/2005-timetable.shtml From owner-freebsd-security@FreeBSD.ORG Tue Sep 20 10:01:30 2005 Return-Path: X-Original-To: freebsd-security@FreeBSD.org Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1564316A41F for ; Tue, 20 Sep 2005 10:01:30 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DF7843D48 for ; Tue, 20 Sep 2005 10:01:29 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id D319F46B3B for ; Tue, 20 Sep 2005 06:01:28 -0400 (EDT) X-Return-Path: X-Received: from cyrus.watson.org ([unix socket]) by cyrus.watson.org (Cyrus v2.1.17) with LMTP; Sat, 17 Sep 2005 08:19:32 -0400 X-Sieve: CMU Sieve 2.2 X-Received: by cyrus.watson.org (Postfix) id 1AAFE46B97; Sat, 17 Sep 2005 08:19:32 -0400 (EDT) X-Delivered-To: trustedbsd-discuss-outgoing@cyrus.watson.org X-Received: by cyrus.watson.org (Postfix, from userid 54) id 1905646B96; Sat, 17 Sep 2005 08:19:32 -0400 (EDT) X-Original-To: trustedbsd-discuss@TrustedBSD.org X-Delivered-To: trustedbsd-discuss@cyrus.watson.org X-Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id DB23E46B8B; Sat, 17 Sep 2005 08:19:31 -0400 (EDT) Date: Sat, 17 Sep 2005 13:19:31 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: trustedbsd-discuss@TrustedBSD.org Message-ID: <20050917125528.M11664@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-trustedbsd-discuss@cyrus.watson.org Precedence: bulk ReSent-Date: Tue, 20 Sep 2005 11:01:18 +0100 (BST) Resent-From: robert Resent-To: freebsd-security@FreeBSD.org ReSent-Subject: File System ACLs: Where to go from here in FreeBSD? ReSent-Message-ID: <20050920110118.W29579@fledge.watson.org> Cc: astrodog@gmail.com Subject: File System ACLs: Where to go from here in FreeBSD? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2005 10:01:30 -0000 The FreeBSD ACL implementation is currently based on a late POSIX.1e draft, and is similar in functionality to the ACL support in Solaris, IRIX, and Linux. It was developed along a similar timeline to the Linux ACL support, and Andreas and I chatted a fair amount along the way so the parallels are strong -- in fact, the Samba ACL support is almost identical, and the ACL API man pages on Linux are directly derived from our ACL man pages (and maybe some of the code?). Differences lie primarily in three areas: (1) We follow the POSIX.1e specification for file creation modes, in which the ACL and umask are combined with the cmode to generate a conservative ACL. This was the same as IRIX, but different from Solaris; Linux adopted the Solaris model. Since then, IRIX has (I believe) also switched to the Solaris model. Our model is "conservative" in that it will never offer broader rights on a file than the umask permits, but it turns out to be quite useful in some environments to allow the ACL on a directory to overide the umask of a program writing files there. (2) We offer a few fewer support routines in user space, such as routines to copy an ACL from one file to another. This has been getting gradually fleshed out over time. (3) We don't offer Solaris-compatible NFSv3 extensions to allow remote management of ACLs via NFS, although the ACLs are enforced on the server so they are "implemented". I'm not sure if these patches were merged to Linux or not, but they were floating around for quite a while. As I see it, there are two directions we can take file system ACL support, and here-in lies the Big Question: (a) We can continue down the POSIX.1e branch of the ACL world, continuing to enhance and refine our support. For example, continuing to flesh out a few missing spots in user space, move over to the now predominent model for generating new file permissions (non-conservative ACL override), implement NFSv3 RPCs. This is some, work, but not a huge amount of work. Or, the a new option that has basically become feasible over the last six years since the POSIX.1e direction was the one we selected: (b) We can consider a migration to NT/NFSv4-style ACLs, which is the route that Darwin has taken. They use the FreeBSD user space ACL library and POSIX.1e interfaces, but use ACLs with more NT-like semantics. In particular, they have notions of taking ownership, slightly finer grained directory controls, etc. This is a lot of work. Option (b) is an interesting new choice as compared to 1999, when NTFS ACLs were in the distinct minority in terms of the syntax and semantics they offered. However, they become much more appealing if we consider that there appears to be a much clearer mapping from NTFS ACLs to NFSv4 ACLs than there is from POSIX.1e ACLs to NFSv4 ACLs. And the fact that Mike Smith at Apple has taken the time to make it sit behind our library for the Darwin implementation on HFS+, etc, is also quite interesting. When I implemented the library, it was my hope that it would support that sort of thing, but we never actually tried :-). If we don't start considering a move to Darwin/NTFS ACLs, then we run into a problem when it comes to implementing NFSv4 ACLs: the mapping and behavior is rather poor and unclear. There's an ID on the topic, which I basically read as saying "This is all rather hard and rather non-ideal". Apple has identified that, for them, compatibility with NT (and possibly NFSv4?) is the way to go, and they may be right. On the other hand, the result is much reduced possibility of clean interoperability with Linux, Solaris, IRIX, and so on. So there's a definite trade-off. If we do make this change, I'd like to also simultaneously consider a change to add an array size field in the ACL structure -- right now, we have a fixed maximum size, and there's a field that says how much of that space is used, but not how much space is available. If we want to support longer ACLs in the future, having a variable array size will improve efficiency and add flexibility. If we want to consider switching to the Darwin ACL model, it sounds like the strategy would be something like the following: (1) Investigate the model closely, and compare it to NTFS. Identify whether any of the significant semantic differences is a problem. (2) Investigate the NFSv4 model closely, and decide if there is a clean and useful mapping or not. If there are nits, approach Apple and decide whether the nits are necessary or not. (3) Produce an implementation on top of UFS2 to experiment with, and see what happens. Specifically, how our current in-kernel APIs and data structures work with it. (4) See whether there is a sensible mapping from existing POSIX.1e ACLs to the newer ACL style, which could be performed at run-time when reading an existing ACL-enabled partition. Specifically, in the long term will we need to support two ACL modes -- a legacy POSIX.1e mode and a new Darwin/NTFS/NFSv4 mode, or can we run entirely in the new mode and run-time translate old ACLs to support a migration path? (6) Investigate what the implications are for applications, especially relating to supporting two ACL models. Will applications get stuck figuring out how they co-exist, or can the kernel help to hide it? (7) Investigate what the implications are for users, who may find that the semantic changes are significant -- and disruptive, potentially. Apple has chosen to provide separate tools for managing ACLs, rather than the POSIX.2e ones, and we might find the same is necessary. It would be interesting to know if systems other than Darwin have started exploring this route. For example, Sun has always been quite interested in NFSv4 -- are they considering or have they made an ACL change that corresponds with the integration of NFSv4 support? My feeling is that NFSv4 might be the compelling argument to consider a migration, and that if we are going to migrate, the sooner we get started with the implementation work, the better. Any thoughts here are welcome. Robert N M Watson To Unsubscribe: send mail to majordomo@trustedbsd.org with "unsubscribe trustedbsd-discuss" in the body of the message From owner-freebsd-security@FreeBSD.ORG Tue Sep 20 21:43:53 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9727116A420 for ; Tue, 20 Sep 2005 21:43:53 +0000 (GMT) (envelope-from all@biosys.net) Received: from mail.rfnj.org (ns1.rfnj.org [66.180.172.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id E925F43D45 for ; Tue, 20 Sep 2005 21:43:50 +0000 (GMT) (envelope-from all@biosys.net) Received: by mail.rfnj.org (Postfix, from userid 65534) id 0BFB336F; Tue, 20 Sep 2005 17:43:26 -0400 (EDT) Received: from megalomaniac.rfnj.org (ool-45736df1.dyn.optonline.net [69.115.109.241]) by mail.rfnj.org (Postfix) with ESMTP id 2BB74350 for ; Tue, 20 Sep 2005 17:43:25 -0400 (EDT) Message-Id: <6.2.3.4.2.20050920172248.027e6918@mail.optonline.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 20 Sep 2005 17:46:12 -0400 To: freebsd-security@freebsd.org From: Allen Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on rfnj.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=20.0 tests=none autolearn=failed version=3.0.4 Subject: Re: File System ACLs: Where to go from here in FreeBSD? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2005 21:43:53 -0000 Long message, excuse the butcher job. On Sat, September 17, 2005 08:19, Robert Watson wrote: >(b) We can consider a migration to NT/NFSv4-style ACLs, which is the route > that Darwin has taken. They use the FreeBSD user space ACL library > and POSIX.1e interfaces, but use ACLs with more NT-like semantics. > In particular, they have notions of taking ownership, slightly finer > grained directory controls, etc. This is a lot of work. >Option (b) is an interesting new choice as compared to 1999, when NTFS >ACLs were in the distinct minority in terms of the syntax and semantics >they offered. However, they become much more appealing if we consider >that there appears to be a much clearer mapping from NTFS ACLs to NFSv4 >ACLs than there is from POSIX.1e ACLs to NFSv4 ACLs. And the fact that >Mike Smith at Apple has taken the time to make it sit behind our library >for the Darwin implementation on HFS+, etc, is also quite interesting. >When I implemented the library, it was my hope that it would support that >sort of thing, but we never actually tried :-). >If we don't start considering a move to Darwin/NTFS ACLs, then we run into >a problem when it comes to implementing NFSv4 ACLs: the mapping and >behavior is rather poor and unclear. From a personal standpoint, going the Darwin/NFSv4/NTFS path is more desirable to me simply because most of the networks I work on are BSD+NT networks. Since I have no Solaris, Linux, or OSX boxes on them and don't use NFS, I'm happy as long as SMB support continues to get better, so either way isn't of a great deal of concern to me. My question is, given that mapping NFSv4 onto the existing POSIX structure is possibly ambiguous, is the reverse also true? With NTFS giving finer grained control, and the implication in your writing that mapping NFSv4 onto Darwin/NTFS is trivial in comparison, is it possible to make the native mode Darwin/NTFS compatible and then map the POSIX side onto that? My very informal investigation of POSIX.1e leads me to believe that implementation on a system with NTFS style ACLs and features would be trivial compared to the reverse; Adding POSIX.1e to NT for example strikes me as fairly easy. It's also of passing interest that POSIX.1e never became a "true" POSIX standard, is incomplete, and has been abandoned by IEEE; Down that road lies even more cross-platform interoperability and compatibility problems I would imagine, if parts of the draft are open to interpretation. From owner-freebsd-security@FreeBSD.ORG Wed Sep 21 16:27:10 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 069AA16A41F for ; Wed, 21 Sep 2005 16:27:10 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37F5643D45 for ; Wed, 21 Sep 2005 16:27:09 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/8.12.11/smtpout02/MantshX 4.0) with ESMTP id j8LGR8Xh005772 for ; Wed, 21 Sep 2005 09:27:09 -0700 (PDT) Received: from [10.1.1.209] (nfw1.codefab.com [199.103.21.225]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id j8LGR6Bn004736 for ; Wed, 21 Sep 2005 09:27:08 -0700 (PDT) To: Robert Watson Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Resent-Date: Wed, 21 Sep 2005 12:26:43 -0400 Message-Id: <14EC098B-60FE-47CF-9747-AEF52D816540@mac.com> Content-Transfer-Encoding: 7bit Resent-To: freebsd-security@freebsd.org From: Charles Swiger Resent-From: Charles Swiger Resent-Message-Id: Date: Tue, 20 Sep 2005 18:25:32 -0400 X-Mailer: Apple Mail (2.734) Cc: trustedbsd-discuss@TrustedBSD.org, astrodog@gmail.com Subject: Re: File System ACLs: Where to go from here in FreeBSD? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2005 16:27:10 -0000 [ ...I guess freebsd-security is the mailing list other replies (Allen) are using... ] Hi, Robert-- This big an email may have frightened away the usual suspects, or perhaps the discussion about bumping library version numbers is stealing too much attention. :-) Nevertheless, I'll toss a few comments into the ring... On Sep 17, 2005, at 8:19 AM, Robert Watson wrote: > (1) We follow the POSIX.1e specification for file creation modes, > in which > the ACL and umask are combined with the cmode to generate a > conservative ACL. This was the same as IRIX, but different from > Solaris; Linux adopted the Solaris model. Since then, IRIX has (I > believe) also switched to the Solaris model. Our model is > "conservative" in that it will never offer broader rights on a > file > than the umask permits, but it turns out to be quite useful in > some > environments to allow the ACL on a directory to overide the > umask of a > program writing files there. The first system I saw ACLs on was AFS, which used ACLs to extend and override the Unix mode bits in a more specific fashion. I believe this is what you refer to as the "Solaris model", but let me try to be more specific: Given a file "foo", with 664 (rw-rw-r--) permissions, you could add a user-specific positive permission (user "adam" can write to the file), and this would apply even if adam was not a member of the group associated with the file. Likewise, you could add a negative permission, such as "no access" for "betty", which would mean betty could not read/write/list/etc the file, even if betty was a member of the group which owns the file "foo". Likewise, you could set up ACLs for groups, where a specific ACL would extend and override the Unix mode bits. If foo was group-owned by staff, you could define a negative ACL for "students" like "no write", and people who were in the students group would not have write access, even if those users were also part of the staff group. [ This was actually a pretty common case, as grad students were employed as TA's or as junior sysadmins keeping the computing clusters going. ] Evaluation order was apply the Unix mode bits as appropriate considering the uid/gid of the process/user accessing the resource, then apply group-based rules, then apply per-user rules, to end up with the final set of access rights. > Option (b) is an interesting new choice as compared to 1999, when > NTFS ACLs were in the distinct minority in terms of the syntax and > semantics they offered. However, they become much more appealing > if we consider that there appears to be a much clearer mapping from > NTFS ACLs to NFSv4 ACLs than there is from POSIX.1e ACLs to NFSv4 > ACLs. And the fact that Mike Smith at Apple has taken the time to > make it sit behind our library for the Darwin implementation on HFS > +, etc, is also quite interesting. When I implemented the library, > it was my hope that it would support that sort of thing, but we > never actually tried :-). I remember Mike from the Darwin lists, he's a good guy (IIRC), and Apple has felt a strong need to implement filesystem and network sharing semantics which work well with Windows/NTFS/CIFS and with Samba. While many people using FreeBSD have less need for such interoperability, it wouldn't hurt to do better, especially if FreeBSD can take advantage of the work already put into Darwin. > If we don't start considering a move to Darwin/NTFS ACLs, then we > run into a problem when it comes to implementing NFSv4 ACLs: the > mapping and behavior is rather poor and unclear. There's an ID on > the topic, which I basically read as saying "This is all rather > hard and rather non-ideal". Apple has identified that, for them, > compatibility with NT (and possibly NFSv4?) is the way to go, and > they may be right. NFS filesharing is much less important to Apple, frankly, and I would not expect them to be taking the lead on NFSv4. I'm not even sure NFSv4 is really on their radar map at all compared to providing an integration of Samba, OpenLDAP, Kerberos with decent GUI management tools in order to provide a reasonable replacement for a Windows domain controller or ADC. > On the other hand, the result is much reduced possibility of clean > interoperability with Linux, Solaris, IRIX, and so on. So there's > a definite trade-off. This concern probably matters more to FreeBSD than to MacOS X. The interoperability issues with ACLs are minor compared with issues such as UFS being case-sensitive, whereas NTFS, CIFS/SMB, and HFS+ all being case-insensitive (but perhaps case-preserving). There's also the issue of Unicode support in filesystem pathnames, which provides a significant advantage to HFS+ for "normal people" [1] using anything outside of ASCII or ISO-8859-1. -- -Chuck [1]: Read this as somebody's grandmother from Russia or China or whatever that wants to name files in her native language. :-) From owner-freebsd-security@FreeBSD.ORG Thu Sep 22 11:11:05 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8EB4F16A41F for ; Thu, 22 Sep 2005 11:11:05 +0000 (GMT) (envelope-from borjamar@sarenet.es) Received: from sollube.sarenet.es (mx1.sarenet.es [194.30.0.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1293843D4C for ; Thu, 22 Sep 2005 11:11:04 +0000 (GMT) (envelope-from borjamar@sarenet.es) Received: from [127.0.0.1] (borja.sarenet.es [192.148.167.77]) by sollube.sarenet.es (Postfix) with ESMTP id 8E6E41D6B for ; Thu, 22 Sep 2005 13:11:00 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v734) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-security@freebsd.org From: Borja Marcos Date: Thu, 22 Sep 2005 13:11:43 +0200 X-Mailer: Apple Mail (2.734) Subject: Mounting filesystems with "noexec" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2005 11:11:05 -0000 Hello, I've been playing a bit with the "noexec" flag for filesystems. It can represent a substantial obstacle against the exploitation of security holes. However, I think it's not perfect yet. First thing, an attempt to execute a program from a noexec-mounted filesystem should be logged. It is either a very significant security event, or it can drive nuts an administrator trying to install software. (I like to mount with noexec filesystems such as /var, /var/ www, /var/spool, /var/tmp, /tmp, /home whenever the users are not supposed to install software...). I opened a PR (a change request, actually) years ago about this, and it was closed with a reasonable answer. http://www.FreeBSD.org/cgi/ query-pr.cgi?pr=15435 However, as far as I know there is no such general logging facility. Wouldn't it be possible for especially sensible events to be logged? The patch I submitted is ugly, but it's better than nothing. There is another change about which I would like to read some opinions. Right now, the "noexec" flag is an all-or-nothing, which greatly reduces its usefulness. Packages and ports use to run programs from /var/tmp or /tmp, and the noexec flags applied to those filesystems won't allow software to be installed. Of course, you can upgrade the status of the filesystems with a mount -u, but that opens a window of opportunity; while the noexec flag has been removed, it is possible for any user to run programs from those directories. I think that it would be useful to have a man point here. What about allowing root, and only root, to run programs from a noexec mounted fs? Its behavior could be changed (for example) with a sysctl variable. My point here is this: I want to prevent a privilege escalation, so I want to prevent a user from executing a file he/she has just written. If it's not possible to execute programs from a directory where a normal user can write, either a public-write directory (/tmp et al) or a directory owned by him (take, for example, a directory with temporary files written by a PHP program or a CGI) it will be very difficult to achieve a privilege escalation. And, anyway, if the intruder found a way to achieve it, he could remove the noexec restriction with a mount -u. I know, both situations have their own caveats (and I can imagine an intruder leaving a periodic process trying to run a program from /var/ tmp), but imho this new behavior can make the noexec feature much more useful. Borja. From owner-freebsd-security@FreeBSD.ORG Thu Sep 22 11:24:51 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 280DD16A41F for ; Thu, 22 Sep 2005 11:24:51 +0000 (GMT) (envelope-from freebsd.macgregor@blueyonder.co.uk) Received: from the-macgregors.org (82-46-96-19.cable.ubr06.stav.blueyonder.co.uk [82.46.96.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C6E543D45 for ; Thu, 22 Sep 2005 11:24:49 +0000 (GMT) (envelope-from freebsd.macgregor@blueyonder.co.uk) X-Urban-Legend: Mail headers contain urban legends Received: from fire (rob@fire.macgregor [192.168.32.100]) (user=freebsd mech=LOGIN bits=0) by the-macgregors.org (8.13.5/8.13.5) with ESMTP id j8MBOkMM017056 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 22 Sep 2005 11:24:46 GMT Message-Id: <200509221124.j8MBOkMM017056@the-macgregors.org> From: "Rob MacGregor" To: Date: Thu, 22 Sep 2005 12:24:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: thread-index: AcW/Zq7Kkf8J0/7STsy5zjj8NFzpMQAAQwwQ X-Virus-Scanned: by amavisd-new Subject: RE: Mounting filesystems with "noexec" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2005 11:24:51 -0000 On Thursday, September 22, 2005 12:12 PM, Borja Marcos <> unleashed the infinite monkeys and produced: > First thing, an attempt to execute a program from a noexec-mounted > filesystem should be logged. It is either a very significant security > event, or it can drive nuts an administrator trying to install > software. (I like to mount with noexec filesystems such as /var, /var/ > www, /var/spool, /var/tmp, /tmp, /home whenever the users are not > supposed to install software...). As long as you can disable/limit the logging. One very nasty "attack" would be to loop trying to run a binary. Blow your logging partition. Somebody could then use that to do other things that would normally be logged, safe in the knowledge that their activities wouldn't be logged. I've seen systems brought to their knees by similar well intentioned logging activities. It's not pretty :) -- Rob | Oh my God! They killed init! You bastards! From owner-freebsd-security@FreeBSD.ORG Thu Sep 22 11:40:36 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8B6516A41F for ; Thu, 22 Sep 2005 11:40:36 +0000 (GMT) (envelope-from borjamar@sarenet.es) Received: from sollube.sarenet.es (mx1.sarenet.es [194.30.0.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BB9443D46 for ; Thu, 22 Sep 2005 11:40:36 +0000 (GMT) (envelope-from borjamar@sarenet.es) Received: from [127.0.0.1] (borja.sarenet.es [192.148.167.77]) by sollube.sarenet.es (Postfix) with ESMTP id 4F2B11921; Thu, 22 Sep 2005 13:40:35 +0200 (CEST) In-Reply-To: <200509221124.j8MBOkMM017056@the-macgregors.org> References: <200509221124.j8MBOkMM017056@the-macgregors.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1C5552E8-3E4C-41D4-80F4-7AAA6FD3EF7D@sarenet.es> Content-Transfer-Encoding: 7bit From: Borja Marcos Date: Thu, 22 Sep 2005 13:41:18 +0200 To: Rob MacGregor X-Mailer: Apple Mail (2.734) Cc: freebsd-security@freebsd.org Subject: Re: Mounting filesystems with "noexec" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2005 11:40:37 -0000 > As long as you can disable/limit the logging. One very nasty > "attack" would be > to loop trying to run a binary. Blow your logging partition. > Somebody could > then use that to do other things that would normally be logged, > safe in the > knowledge that their activities wouldn't be logged. > > I've seen systems brought to their knees by similar well > intentioned logging > activities. It's not pretty :) That's out of the question, of course :) A sysctl could control it. Anyway, the same can happen with zillions of logged events. Borja. From owner-freebsd-security@FreeBSD.ORG Thu Sep 22 11:59:26 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B150616A41F for ; Thu, 22 Sep 2005 11:59:26 +0000 (GMT) (envelope-from markzero@logik.ath.cx) Received: from addr9.addr.com (addr9.addr.com [38.113.244.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A8B243D45 for ; Thu, 22 Sep 2005 11:59:26 +0000 (GMT) (envelope-from markzero@logik.ath.cx) Received: from logik.ath.cx (localhost [127.0.0.1]) by addr9.addr.com (8.12.11/8.12.8/Submit) with ESMTP id j8MBxNMf029852 for ; Thu, 22 Sep 2005 04:59:24 -0700 (PDT) Received: by logik.ath.cx (Postfix, from userid 1001) id 9725D6406; Thu, 22 Sep 2005 12:59:23 +0100 (BST) Date: Thu, 22 Sep 2005 12:59:23 +0100 From: markzero To: freebsd-security@freebsd.org Message-ID: <20050922115923.GB73668@logik.internal.network> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="s/l3CgOIzMHHjg/5" Content-Disposition: inline X-GPG-Key: http://darklogik.org/pub/pgp/pgp.txt X-Fingerprint: 0160 A46A 9A48 D3B0 C92F B690 17FB 4B72 0207 ED43 X-ADDRSpamFilter: Passed, probability (0%) X-ADDRSignature: 281B41DA Subject: Re: Mounting filesystems with "noexec" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2005 11:59:26 -0000 --s/l3CgOIzMHHjg/5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ oops, ommitted the CC line to freebsd-security@ ] May I throw in my two euros? security.noexec.log_bin: /sbin/trusted_logging_prog security.noexec.log_maxrate: N security.noexec.log_enabled: 0 security.noexec.log_enabled refuses to enable itself unless security.noexec.log_bin exists and has the correct permissions, etc. security.noexec.log_maxrate is the maximum allowed number of logs per second. If this rate is exceeded, wait for a preset grace period and then if logs are still pouring in, stop accepting logs and periodically write a loud WARNING line to the log (this would be watched by something like logcheck to alert the administrator). This would prevent the flood of logging taking out the machine and the grace period should allow enough logging to make sure we know who the culprit was. Of course, this is all theoretical. There's most likely a glaring error or omission... M PS: could this be implemented with the MAC framework somehow? Isn't this sort of thing exactly what it was meant for? --=20 pgp: http://www.darklogik.org/pub/pgp/pgp.txt 0160 A46A 9A48 D3B0 C92F B690 17FB 4B72 0207 ED43 ----- End forwarded message ----- --=20 pgp: http://www.darklogik.org/pub/pgp/pgp.txt 0160 A46A 9A48 D3B0 C92F B690 17FB 4B72 0207 ED43 --s/l3CgOIzMHHjg/5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iQIVAwUBQzKcmhf7S3ICB+1DAQoxOhAAqxgkX5TwmsAfxwhLK66tp6yJES66y4xP PatXT98/qr+GqcK2TgNV2KVp3XLxFN/AAZ59zTefOT8Y0NQ6hAZ/SGHOwceWZNph PUgQSvhp35XSklYA3t0zTOX7D7lNp7G5vZEi99rfOASDuLmW8ZDyCyr+3LUpXJFh PqnaX29EWvA3vCe83Abj86T9N4tRf/GDgUXQRx8z0clkxJuWCQUsYggFCdQyy9Y1 9HssS+YBuup9PcdoOEnzbn2wwstkWJf683LvncHW1ZWjqJCTPjLrFExEvpRi5++/ 6oVqudd0ebauJUwhcDjJ0FWrlMG3SPICuTNBcThUNAnpuGSzyzOuBoLyqdTOKIUU MxbAZT1gUGGUuiupuOWO+AdWcigQwxHhsMgBjxY0Nw54kcT+FtL6Lq6GbxkJxzDy 4HqZhlP1gp9o2J4J8Y1bTbLnVTysjfpS2iG//rwLBWz2NxuWLGx4yPtIJcv+qPgL 5dpNlkeEK1ypweVq/aJ43bM68YG462/o9OpamYDqJEHeRaiWhoutdaIY46uqCCKp 9NnJy7deXjR2zq1H2hRQsY9qJI57i2XZe2QVKKKmpVligPajhugjJ9d4lyZXxS2w qLZWPNM6wB+GFLhYqKAO8bkPCU3sXmIuIhS+QenS2Y4I4LMe6tnbPrS63aSK0rCS CfkrIqzpiW0= =EOSI -----END PGP SIGNATURE----- --s/l3CgOIzMHHjg/5-- From owner-freebsd-security@FreeBSD.ORG Thu Sep 22 12:17:16 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E33816A41F for ; Thu, 22 Sep 2005 12:17:16 +0000 (GMT) (envelope-from simon@eddie.nitro.dk) Received: from nfishbone.nitro.dk (cpe.atm2-0-71337.0x535ccf26.taanxx2.customer.tele.dk [83.92.207.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E97343D55 for ; Thu, 22 Sep 2005 12:17:14 +0000 (GMT) (envelope-from simon@eddie.nitro.dk) Received: from eddie.nitro.dk (localhost [127.0.0.1]) by nfishbone.nitro.dk (Postfix) with ESMTP id 1D6AC61C2C for ; Thu, 22 Sep 2005 14:17:10 +0200 (CEST) Received: by eddie.nitro.dk (Postfix, from userid 1000) id 62C4D11A320; Thu, 22 Sep 2005 14:13:27 +0200 (CEST) Date: Thu, 22 Sep 2005 14:13:27 +0200 From: "Simon L. Nielsen" To: Borja Marcos Message-ID: <20050922121326.GA66046@eddie.nitro.dk> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Cc: freebsd-security@freebsd.org Subject: Re: Mounting filesystems with "noexec" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2005 12:17:16 -0000 --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2005.09.22 13:11:43 +0200, Borja Marcos wrote: > I've been playing a bit with the "noexec" flag for filesystems. It > can represent a substantial obstacle against the exploitation of > security holes. Please note the following from the mount(8) manual page: noexec Do not allow execution of any binaries on the mounted file system. This option is useful for a server that has file systems containing binaries for architectures other than its own. Note: This option was not designed as a security feature and no guarantee is made that it will prevent malicious code execution; for example, it is still possible to execute scripts which reside on a noexec mounted partition. I don't know if it makes sense to log noexec failures, but at least it's important that people don't completely rely on noexec for security. --=20 Simon L. Nielsen --2fHTh5uZTiUOsy+g Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDMp/mh9pcDSc1mlERAnLOAJ0WqGjhfVfyTTwW4bdBrCWSxI7/3ACggZVD YBe2yVRDSJQcW0PPckKsSdc= =wk35 -----END PGP SIGNATURE----- --2fHTh5uZTiUOsy+g-- From owner-freebsd-security@FreeBSD.ORG Thu Sep 22 15:27:22 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E0E516A41F for ; Thu, 22 Sep 2005 15:27:22 +0000 (GMT) (envelope-from markzero@logik.ath.cx) Received: from addr9.addr.com (addr9.addr.com [38.113.244.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0234143D45 for ; Thu, 22 Sep 2005 15:27:21 +0000 (GMT) (envelope-from markzero@logik.ath.cx) Received: from logik.ath.cx (localhost [127.0.0.1]) by addr9.addr.com (8.12.11/8.12.8/Submit) with ESMTP id j8MFRJGr016876 for ; Thu, 22 Sep 2005 08:27:20 -0700 (PDT) Received: by logik.ath.cx (Postfix, from userid 1001) id E220162AB; Thu, 22 Sep 2005 16:27:18 +0100 (BST) Date: Thu, 22 Sep 2005 16:27:18 +0100 From: markzero To: freebsd-security@freebsd.org Message-ID: <20050922152718.GB91509@logik.internal.network> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RnlQjJ0d97Da+TV1" Content-Disposition: inline X-GPG-Key: http://darklogik.org/pub/pgp/pgp.txt X-Fingerprint: 0160 A46A 9A48 D3B0 C92F B690 17FB 4B72 0207 ED43 X-ADDRSpamFilter: Passed, probability (1%) X-ADDRSignature: 1ABF5D4A Subject: Tunnel-only SSH keys X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2005 15:27:22 -0000 --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello. I once read somewhere that it's possible to limit SSH pubkeys to 'tunnel-only'. I can't seem to find any information about this in any of the usual places. I'm going to be deploying a few servers in a couple of days and I'd like them to log to a central server over an SSH tunnel (using syslog-ng) however I'd like to prevent actual logins (hence 'tunnel-only'). Can this be done with OpenSSH? I'd like to try and stay away from the complexities of a chrooted-stunnel for now... cheers, M --=20 pgp: http://www.darklogik.org/pub/pgp/pgp.txt 0160 A46A 9A48 D3B0 C92F B690 17FB 4B72 0207 ED43 --RnlQjJ0d97Da+TV1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iQIVAwUBQzLNVRf7S3ICB+1DAQpHhRAAvno1gxbg3GrCsuKAf0ALMH9B/AOd6+od iSTGDMKGV3DatoZbyVTql13Sak8n9IUjt8RRoycmBgqYQXcggRrtuf40N4gI9kIK SjiSMWFxTDyxX/iyftb/ca+LA8eGbPCyJRfFW2ZO5hB6aX9Q0yFQjXlhmF+TsOTy VPiBbNp7bdK3lap1rSWxyvmtGl0jHzo4JY+5CU5GSGbQrf8hfCfuhksluCiSNMLq gi7+uBLs3Oa/F256FHYViShyN2BOKCksrXzPQ58FymfgZ+nRuN2yxfT1t8vvz3ZX 7C3bzkVZSyXpqDG6DWWl22Ypt7I9tOisFl0EAfxrNkY9B8h/UMhg/P7Hpi34Of95 NY/BWGO8U8iOMNuHTWDmxn1+EL+W8+P6eizAzdPbPtLBI6h3HCW0YXx96uVcD2Xp JkzbOxQlp12QEfrKBYcXJU1jrklZaE8KgM+cK3sSIMQNmnW5X5mbIWY9NZFl/d2x bVWBpfKXG/JWrXf1fxwPWHB8ZOtlvp9pk1dEAr7QC+c+H0g/7FtjJTVgPbNcf7DW amE+bprUo/bEw48Ow9ZYFYBHgalCGV+6Lwq/gobAe6sgCg4XYGZZTs8a6FGYP21B 2zu6St83ZjeT0tez+GbGy915e0raU0qyOokxevZ4ggRU4LRs7CFi3T9s3XP0t9p0 OhxjGv8to6Q= =3N/I -----END PGP SIGNATURE----- --RnlQjJ0d97Da+TV1-- From owner-freebsd-security@FreeBSD.ORG Thu Sep 22 16:10:03 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA51716A41F for ; Thu, 22 Sep 2005 16:10:03 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8333D43D49 for ; Thu, 22 Sep 2005 16:10:03 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by smtp3-g19.free.fr (Postfix) with ESMTP id 96BCE2507E; Thu, 22 Sep 2005 18:10:02 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id C6A83405D; Thu, 22 Sep 2005 18:09:59 +0200 (CEST) Date: Thu, 22 Sep 2005 18:09:59 +0200 From: Jeremie Le Hen To: markzero Message-ID: <20050922160959.GQ24643@obiwan.tataz.chchile.org> References: <20050922152718.GB91509@logik.internal.network> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050922152718.GB91509@logik.internal.network> User-Agent: Mutt/1.5.10i Cc: freebsd-security@freebsd.org Subject: Re: Tunnel-only SSH keys X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2005 16:10:04 -0000 Hi, > I once read somewhere that it's possible to limit SSH pubkeys to > 'tunnel-only'. I can't seem to find any information about this > in any of the usual places. > > I'm going to be deploying a few servers in a couple of days and > I'd like them to log to a central server over an SSH tunnel (using > syslog-ng) however I'd like to prevent actual logins (hence > 'tunnel-only'). > > Can this be done with OpenSSH? I'd like to try and stay away from > the complexities of a chrooted-stunnel for now... I think you can use /bin/false as shell, and then use ``ssh -nN'' from the client. I've not tested this, but I guess this should work. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-security@FreeBSD.ORG Thu Sep 22 16:22:41 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDB8816A41F for ; Thu, 22 Sep 2005 16:22:41 +0000 (GMT) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9081343D45 for ; Thu, 22 Sep 2005 16:22:39 +0000 (GMT) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id j8MGMc3f089370 for ; Thu, 22 Sep 2005 09:22:38 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.1/Submit) id j8MGMcXI089369 for freebsd-security@freebsd.org; Thu, 22 Sep 2005 09:22:38 -0700 (PDT) (envelope-from david) Date: Thu, 22 Sep 2005 09:22:38 -0700 From: David Wolfskill To: freebsd-security@freebsd.org Message-ID: <20050922162238.GZ54033@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , freebsd-security@freebsd.org References: <20050922152718.GB91509@logik.internal.network> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050922152718.GB91509@logik.internal.network> User-Agent: Mutt/1.4.2.1i Subject: Re: Tunnel-only SSH keys X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2005 16:22:42 -0000 On Thu, Sep 22, 2005 at 04:27:18PM +0100, markzero wrote: > Hello. > > I once read somewhere that it's possible to limit SSH pubkeys to > 'tunnel-only'. I can't seem to find any information about this > in any of the usual places. > ... > Can this be done with OpenSSH? I'd like to try and stay away from > the complexities of a chrooted-stunnel for now... See the section "AUTHORIZED_KEYS FILE FORMAT" in the sshd man page. There is also a discussion of this in the O'Reilly _SSH_ book. Peace, david -- David H. Wolfskill david@catwhisker.org Prediction is difficult, especially if it involves the future. -- Niels Bohr See http://www.catwhisker.org/~david/publickey.gpg for public key. From owner-freebsd-security@FreeBSD.ORG Thu Sep 22 16:32:07 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCBDE16A41F for ; Thu, 22 Sep 2005 16:32:07 +0000 (GMT) (envelope-from markzero@logik.ath.cx) Received: from addr9.addr.com (addr9.addr.com [38.113.244.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9606543D45 for ; Thu, 22 Sep 2005 16:32:07 +0000 (GMT) (envelope-from markzero@logik.ath.cx) Received: from logik.ath.cx (localhost [127.0.0.1]) by addr9.addr.com (8.12.11/8.12.8/Submit) with ESMTP id j8MGW3AW045150; Thu, 22 Sep 2005 09:32:04 -0700 (PDT) Received: by logik.ath.cx (Postfix, from userid 1001) id 9D58D62AB; Thu, 22 Sep 2005 17:32:03 +0100 (BST) Date: Thu, 22 Sep 2005 17:32:03 +0100 From: markzero To: David Wolfskill Message-ID: <20050922163203.GD91509@logik.internal.network> References: <20050922152718.GB91509@logik.internal.network> <20050922162238.GZ54033@bunrab.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="eHhjakXzOLJAF9wJ" Content-Disposition: inline In-Reply-To: <20050922162238.GZ54033@bunrab.catwhisker.org> X-GPG-Key: http://darklogik.org/pub/pgp/pgp.txt X-Fingerprint: 0160 A46A 9A48 D3B0 C92F B690 17FB 4B72 0207 ED43 X-ADDRSpamFilter: Passed, probability (0%) X-ADDRSignature: 19DA4F86 Cc: freebsd-security@freebsd.org Subject: Re: Tunnel-only SSH keys X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2005 16:32:08 -0000 --eHhjakXzOLJAF9wJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > > Hello. > >=20 > > I once read somewhere that it's possible to limit SSH pubkeys to > > 'tunnel-only'. I can't seem to find any information about this > > in any of the usual places. > > ... > > Can this be done with OpenSSH? I'd like to try and stay away from > > the complexities of a chrooted-stunnel for now... >=20 > See the section "AUTHORIZED_KEYS FILE FORMAT" in the sshd man page. >=20 > There is also a discussion of this in the O'Reilly _SSH_ book. Oops, forgot to check the manual page. "It couldn't possibly be there, that's far too obvious..." Thanks, M --=20 pgp: http://www.darklogik.org/pub/pgp/pgp.txt 0160 A46A 9A48 D3B0 C92F B690 17FB 4B72 0207 ED43 --eHhjakXzOLJAF9wJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iQIVAwUBQzLcghf7S3ICB+1DAQq2gw//Xtljgmvgd9NxE+znUG+ks7Wg0zUa+x1c mwjy9AbdCjB3/EPtY4PAEa814pe6g993ZNdjXw2i9yZvRwM3oPCmBCM4CReWFA1G VoRnp3rk7EoJvdspusMWjFjgfDWe7cGrRTZjmHIrskQgM3I+hTG11wWpzx+C+KHB EP7CGup6+i3TJClCLOdEKCB8P9Ue/ch2dQkduVWlh5j5Z9jmKRxzbcrbaPWWt3Wr fDzRWCKMRQAUPiN0e3D7bBKVw5HZyF0wi/gi5Ju2DI20zTN5gD9DkxOwzh1kaE7o mpK+TvLfsC0m6hLuCmb1WrVSHxfhuTBUB6EUk4KF9HQr3FIhZStRzhscCUOyBeO8 Ibnrv7D6i9PpGJEwSYr02mlplVtnZ6YKwEIsfmWF9Y9CdfakRFjDLb0fLf55V3JF yelCNhs0+WcJ4WkS420fty43Jcm50yBpcmIqY7un6yWRLY6VypR0JWUbR09fpIlE hTLwPm1xjYLwtjCY/W82mYYmktHkhKeymXqDsWAjxkXejX9ROGvhtMRX+EGuN1RE sH5hUFVXKwctn58ubcf4y+Ljc2iUYCob+PInG/cKMTk054Ta2oNZhxUHJIc/kLRP rxH5TBvfkEUc2B8/PM2LxicpLcNhz8rW5Ehe5oAR0Re7lOZdFkSimG0QU2VU0jvY 97iSj377DQA= =ym92 -----END PGP SIGNATURE----- --eHhjakXzOLJAF9wJ-- From owner-freebsd-security@FreeBSD.ORG Thu Sep 22 17:33:53 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FA3416A41F for ; Thu, 22 Sep 2005 17:33:53 +0000 (GMT) (envelope-from reichert@numachi.com) Received: from meisai.numachi.com (meisai.numachi.com [198.175.254.6]) by mx1.FreeBSD.org (Postfix) with SMTP id 41D4A43D48 for ; Thu, 22 Sep 2005 17:33:51 +0000 (GMT) (envelope-from reichert@numachi.com) Received: (qmail 78797 invoked from network); 22 Sep 2005 17:33:45 -0000 Received: from natto.numachi.com (198.175.254.216) by meisai.numachi.com with SMTP; 22 Sep 2005 17:33:45 -0000 Received: (qmail 42885 invoked by uid 1001); 22 Sep 2005 17:33:47 -0000 Date: Thu, 22 Sep 2005 13:33:47 -0400 From: Brian Reichert To: David Wolfskill , freebsd-security@freebsd.org Message-ID: <20050922173347.GI74605@numachi.com> References: <20050922152718.GB91509@logik.internal.network> <20050922162238.GZ54033@bunrab.catwhisker.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050922162238.GZ54033@bunrab.catwhisker.org> User-Agent: Mutt/1.5.9i Cc: Subject: Re: Tunnel-only SSH keys X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2005 17:33:53 -0000 On Thu, Sep 22, 2005 at 09:22:38AM -0700, David Wolfskill wrote: > On Thu, Sep 22, 2005 at 04:27:18PM +0100, markzero wrote: > > Hello. > > > > I once read somewhere that it's possible to limit SSH pubkeys to > > 'tunnel-only'. I can't seem to find any information about this > > in any of the usual places. > > ... > > Can this be done with OpenSSH? I'd like to try and stay away from > > the complexities of a chrooted-stunnel for now... > > See the section "AUTHORIZED_KEYS FILE FORMAT" in the sshd man page. > > There is also a discussion of this in the O'Reilly _SSH_ book. Sorry for the arm-wave (in that I don't have the details of this rumor), but I recall it's possible, via a client, to screw with the remote environment, as to supply a different shell; that would affect these tactics, perhaps. > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > Prediction is difficult, especially if it involves the future. -- Niels Bohr -- Brian Reichert 55 Crystal Ave. #286 Daytime number: (603) 434-6842 Derry NH 03038-1725 USA BSD admin/developer at large From owner-freebsd-security@FreeBSD.ORG Thu Sep 22 18:01:10 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 353DE16A41F for ; Thu, 22 Sep 2005 18:01:10 +0000 (GMT) (envelope-from reichert@numachi.com) Received: from meisai.numachi.com (meisai.numachi.com [198.175.254.6]) by mx1.FreeBSD.org (Postfix) with SMTP id 749EB43D45 for ; Thu, 22 Sep 2005 18:01:09 +0000 (GMT) (envelope-from reichert@numachi.com) Received: (qmail 79448 invoked from network); 22 Sep 2005 18:01:05 -0000 Received: from natto.numachi.com (198.175.254.216) by meisai.numachi.com with SMTP; 22 Sep 2005 18:01:05 -0000 Received: (qmail 43100 invoked by uid 1001); 22 Sep 2005 18:01:08 -0000 Date: Thu, 22 Sep 2005 14:01:08 -0400 From: Brian Reichert To: Jeremie Le Hen Message-ID: <20050922180108.GJ74605@numachi.com> References: <20050922152718.GB91509@logik.internal.network> <20050922160959.GQ24643@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050922160959.GQ24643@obiwan.tataz.chchile.org> User-Agent: Mutt/1.5.9i Cc: freebsd-security@freebsd.org, markzero Subject: Re: Tunnel-only SSH keys X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2005 18:01:10 -0000 On Thu, Sep 22, 2005 at 06:09:59PM +0200, Jeremie Le Hen wrote: > Hi, > > > I once read somewhere that it's possible to limit SSH pubkeys to > > 'tunnel-only'. I can't seem to find any information about this > > in any of the usual places. > > > > I'm going to be deploying a few servers in a couple of days and > > I'd like them to log to a central server over an SSH tunnel (using > > syslog-ng) however I'd like to prevent actual logins (hence > > 'tunnel-only'). > > > > Can this be done with OpenSSH? I'd like to try and stay away from > > the complexities of a chrooted-stunnel for now... > > I think you can use /bin/false as shell, and then use ``ssh -nN'' > from the client. I've not tested this, but I guess this should > work. See this discussion: http://www.blacksheepnetworks.com/security/hack/scponly.txt > Regards, > -- > Jeremie Le Hen > < jeremie at le-hen dot org >< ttz at chchile dot org > -- Brian Reichert 55 Crystal Ave. #286 Daytime number: (603) 434-6842 Derry NH 03038-1725 USA BSD admin/developer at large From owner-freebsd-security@FreeBSD.ORG Thu Sep 22 22:12:48 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA21916A41F for ; Thu, 22 Sep 2005 22:12:48 +0000 (GMT) (envelope-from andreas@romab.com) Received: from rot13.romab.com (rot13.romab.com [194.52.231.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id F00A543D48 for ; Thu, 22 Sep 2005 22:12:47 +0000 (GMT) (envelope-from andreas@romab.com) Received: by rot13.romab.com (Postfix, from userid 30002) id DE30D29D5FB; Fri, 23 Sep 2005 00:12:45 +0200 (CEST) Received: from [127.0.0.1] (rot13.romab.com [194.52.231.20]) by rot13.romab.com (Postfix) with ESMTP id A82C929D59A; Fri, 23 Sep 2005 00:12:44 +0200 (CEST) Message-ID: <43332CD7.4070107@romab.com> Date: Fri, 23 Sep 2005 00:14:47 +0200 From: Andreas Jonsson User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050326) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Borja Marcos References: In-Reply-To: X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on rot13.romab.com X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.3 Cc: freebsd-security@freebsd.org Subject: Re: Mounting filesystems with "noexec" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2005 22:12:48 -0000 Borja Marcos wrote: > > Hello, > > I've been playing a bit with the "noexec" flag for filesystems. It can > represent a substantial obstacle against the exploitation of security > holes. > I think TPE (trusted path execution) would be the prefered solution to this problem. As others have pointed out, circumventing the 'noexec' attribute is pretty easy. That said, i don't think it is a bad idea to use this, but one should be aware of how this defense might be defeated. Instead of running "./script.sh" or "./script.pl" you just have to type /bin/sh script.sh or /usr/bin/perl script.pl which gives pretty much everything you need when it comes to using exploits. In linux you could also circumvent it by using /lib/ld.so exploit, but i'm not sure if that is "fixed" now or not. TPE requires all the binaries and subpaths to be owned by root. ie /home/ /home/user and /home/user/file need to be owned by root to allow execution. GRSec for linux provides this functionality aswell as Stephanie does for OpenBSD. Both solves the problems with interperters aswell, but i havent looked into how, just used system that uses TPE. If there are problems with TPE that people know about, please tell. Obvious things are mounted filesystems from other machines, like nfs. /andreas From owner-freebsd-security@FreeBSD.ORG Fri Sep 23 07:04:30 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B3FF16A41F for ; Fri, 23 Sep 2005 07:04:30 +0000 (GMT) (envelope-from borjamar@sarenet.es) Received: from sollube.sarenet.es (mx1.sarenet.es [194.30.0.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2DB743D45 for ; Fri, 23 Sep 2005 07:04:29 +0000 (GMT) (envelope-from borjamar@sarenet.es) Received: from [127.0.0.1] (borja.sarenet.es [192.148.167.77]) by sollube.sarenet.es (Postfix) with ESMTP id 85E1D1ED0; Fri, 23 Sep 2005 09:04:28 +0200 (CEST) In-Reply-To: <43332CD7.4070107@romab.com> References: <43332CD7.4070107@romab.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <726F1E71-D4D9-4C34-848D-868C1158834E@sarenet.es> Content-Transfer-Encoding: 7bit From: Borja Marcos Date: Fri, 23 Sep 2005 09:05:13 +0200 To: Andreas Jonsson X-Mailer: Apple Mail (2.734) Cc: freebsd-security@freebsd.org Subject: Re: Mounting filesystems with "noexec" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2005 07:04:30 -0000 > Instead of running "./script.sh" or "./script.pl" you just have to > type > /bin/sh script.sh or /usr/bin/perl script.pl which gives pretty much > everything you need when it comes to using exploits. In linux you > could > also circumvent it by using /lib/ld.so exploit, but i'm not sure if > that > is "fixed" now or not. I'm well aware of this, obviously :-) But, with TPE or without TPE, any command with a script language, be it a shell, Perl, Tcl, or whatever (even Java) should perform that check, which is not a good design practice. That said, my point is this: the amount of damage you can do from a "native" program is greater than the damage you can achieve from a script language, afaik. At least a privilege escalation should be harder to obtain. I'm not sure about some languages such as Perl, though. Of course, this is only one among a bigger set of security measures. Borja. From owner-freebsd-security@FreeBSD.ORG Fri Sep 23 17:22:21 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39C5016A41F for ; Fri, 23 Sep 2005 17:22:21 +0000 (GMT) (envelope-from suporte@wahtec.com.br) Received: from galois.wahtec.com.br (galois.wahtec.com.br [200.96.65.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1E8143D49 for ; Fri, 23 Sep 2005 17:22:18 +0000 (GMT) (envelope-from suporte@wahtec.com.br) Received: (qmail 65699 invoked by uid 98); 23 Sep 2005 17:22:16 -0000 Received: from 127.0.0.1 by brasil.intranet (envelope-from , uid 1024) with qmail-scanner-1.24 (f-prot: 4.4.7/3.14.13. spamassassin: 2.63. Clear:RC:1(127.0.0.1):. Processed in 0.115739 secs); 23 Sep 2005 17:22:16 -0000 X-Qmail-Scanner-Mail-From: suporte@wahtec.com.br via brasil.intranet X-Qmail-Scanner: 1.24 (Clear:RC:1(127.0.0.1):. Processed in 0.115739 secs) Received: from unknown (HELO buddyguy) (arisjr@unknown) by unknown with SMTP; 23 Sep 2005 17:22:15 -0000 From: Aristeu Gil Alves Jr To: freebsd-security@freebsd.org Date: Fri, 23 Sep 2005 17:22:13 +0000 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509231722.14978.suporte@wahtec.com.br> Subject: Re: Mounting filesystems with "noexec" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2005 17:22:21 -0000 >> Borja Marcos wrote: >> >> Hello, >> >> I've been playing a bit with the "noexec" flag for filesystems. It can >> represent a substantial obstacle against the exploitation of security >> holes. >> > > I think TPE (trusted path execution) would be the prefered solution to > this problem. As others have pointed out, circumventing the 'noexec' > attribute is pretty easy. That said, i don't think it is a bad idea to > use this, but one should be aware of how this defense might be defeated. > > Instead of running "./script.sh" or "./script.pl" you just have to type > /bin/sh script.sh or /usr/bin/perl script.pl which gives pretty much > everything you need when it comes to using exploits. In linux you could > also circumvent it by using /lib/ld.so exploit, but i'm not sure if that > is "fixed" now or not. > > TPE requires all the binaries and subpaths to be owned by root. ie > /home/ > /home/user and /home/user/file need to be owned by root to allow > execution. GRSec for linux provides this functionality aswell as > Stephanie does for OpenBSD. > > Both solves the problems with interperters aswell, but i havent looked > into how, just used system that uses TPE. If there are problems with > TPE that people know about, please tell. Obvious things are mounted > filesystems from other machines, like nfs. > > /andreas IMHO, It can be used as a security layer, if the noexec partition is used by a chroot'ed aplication. chroot'ing on the noexec partition would increase the eficiency of noexec. I think at least the intruder won't feel in a confortable enviroment when exploiting the chrooted aplication... --Aristeu From owner-freebsd-security@FreeBSD.ORG Fri Sep 23 21:31:18 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 039D116A421 for ; Fri, 23 Sep 2005 21:31:18 +0000 (GMT) (envelope-from security@gugol.ru) Received: from gugol.ru (gugol.ru [85.21.77.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9ADCA43D62 for ; Fri, 23 Sep 2005 21:31:15 +0000 (GMT) (envelope-from security@gugol.ru) Message-ID: <43345736.3090602@gugol.ru> Date: Fri, 23 Sep 2005 23:27:50 +0400 From: Vasiliy User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Borja Marcos References: <43332CD7.4070107@romab.com> <726F1E71-D4D9-4C34-848D-868C1158834E@sarenet.es> In-Reply-To: <726F1E71-D4D9-4C34-848D-868C1158834E@sarenet.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by antivirus at gugol.ru Cc: freebsd-security@freebsd.org Subject: Re: Mounting filesystems with "noexec" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2005 21:31:18 -0000 > That said, my point is this: the amount of damage you can do from a > "native" program is greater than the damage you can achieve from a > script language, afaik. This is not the case, unfortunately. There are already a lot of exploits written in Perl, Python. Just google for "perl exploit" or something similar. And this exploits are not like "construct proper GET request for another SQL injection", but complicated buffer-overflowing ones. Also exists some tutorials like this: http://community.core-sdi.com/~juliano/withperl.txt > At least a privilege escalation should be > harder to obtain. I'm not sure about some languages such as Perl, though. As was said above, perfoming privilege escalation in scripting languages is not harder than in C, for example. So, using "noexec" option for preventing malicious code from execution is not desirable. -- wbr, Vasiliy From owner-freebsd-security@FreeBSD.ORG Fri Sep 23 21:57:59 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C422716A41F for ; Fri, 23 Sep 2005 21:57:59 +0000 (GMT) (envelope-from markzero@logik.ath.cx) Received: from addr9.addr.com (addr9.addr.com [38.113.244.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E9D343D4C for ; Fri, 23 Sep 2005 21:57:59 +0000 (GMT) (envelope-from markzero@logik.ath.cx) Received: from logik.ath.cx (localhost [127.0.0.1]) by addr9.addr.com (8.12.11/8.12.8/Submit) with ESMTP id j8NLtuU0036837 for ; Fri, 23 Sep 2005 14:55:57 -0700 (PDT) Received: by logik.ath.cx (Postfix, from userid 1001) id 91F5962AB; Fri, 23 Sep 2005 22:55:56 +0100 (BST) Date: Fri, 23 Sep 2005 22:55:56 +0100 From: markzero To: freebsd-security@freebsd.org Message-ID: <20050923215556.GB72838@logik.internal.network> References: <43332CD7.4070107@romab.com> <726F1E71-D4D9-4C34-848D-868C1158834E@sarenet.es> <43345736.3090602@gugol.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1UWUbFP1cBYEclgG" Content-Disposition: inline In-Reply-To: <43345736.3090602@gugol.ru> X-GPG-Key: http://darklogik.org/pub/pgp/pgp.txt X-Fingerprint: 0160 A46A 9A48 D3B0 C92F B690 17FB 4B72 0207 ED43 Subject: Re: mounting filesystems with "noexec" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2005 21:57:59 -0000 --1UWUbFP1cBYEclgG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable With all that has been said so far, what is the actual point of the noexec flag?=20 M --=20 pgp: http://www.darklogik.org/pub/pgp/pgp.txt 0160 A46A 9A48 D3B0 C92F B690 17FB 4B72 0207 ED43 --1UWUbFP1cBYEclgG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iQIVAwUBQzR56xf7S3ICB+1DAQpMlg//aO/XhDXEocflQxcQ+urynYfNn7Yu6WSI uL0w0+nv2lqUY1Vu/T6oCCAf7t4v6QDaolnfMVem5weTELOlL9KBYwWW9/qkwvpB nWzd76TObHx/Y0GgdPKl4lvs0yBp2loKIOKoBfSX7KZHaPzl7+zCpEzcqCr9l6Jp nM4GNFPFYUqJRQAcFVIGE5cNXdDFGpkHntXn9+ya7YX6bvQ0xkqL9ZzOk0LMJuzs xWkdGclYCc+PnVQ+sG+Jx7E3AxVri2EtwY+cWSzduI2BWADCFGW/vtqhhHRUapGb F4Rd9tvVcgRGiDWUcy31fw09fqJF67d6PVwZgf+eE0pw4FnwmjORi3A6+e7qKWlX 9aC6QexZ+bjdqNUa3fJ8FchAC5Y5aC/XpsqNspvfeFtAEVnAi3Gz6U8KVHEXFj1m 4tt6cecS8AWSrqGbVqoQxb7ghK11oESoOm/XZH/usv/kc71EWaYV4n+x2v+7Qsl5 sERERKJ48YqkgdR9zmstsjdQmByKVwlAS+axiMKwaKd0nFaPbAWr8zkjNTrJQHdk RLTZayjs2OZCDE26Uhr9Nf35JMahhRVDDH/9st/8hAbkuT5IVb0t6x6ADMbiU02m iJ8/dfFTO/Lv58+B0G80vd9f8IgEnhRzVQ8SiIlTshSqFvCv/Ag9Qz+fAI2blkwk qx0Y2TKveaE= =/F8z -----END PGP SIGNATURE----- --1UWUbFP1cBYEclgG-- From owner-freebsd-security@FreeBSD.ORG Fri Sep 23 22:03:05 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1EBCE16A41F for ; Fri, 23 Sep 2005 22:03:05 +0000 (GMT) (envelope-from randall@ucsb.edu) Received: from isber.ucsb.edu (research.isber.ucsb.edu [128.111.147.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id D719743D48 for ; Fri, 23 Sep 2005 22:03:04 +0000 (GMT) (envelope-from randall@ucsb.edu) Received: from localhost ([127.0.0.1] helo=[128.111.147.11]) by isber.ucsb.edu with esmtp (Exim 3.36 #2) id 1EIvdA-000IvF-00; Fri, 23 Sep 2005 15:02:56 -0700 Message-ID: <43347BC3.7000308@ucsb.edu> Date: Fri, 23 Sep 2005 15:03:47 -0700 From: "randall s. ehren" Organization: ISBER User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: markzero References: <43332CD7.4070107@romab.com> <726F1E71-D4D9-4C34-848D-868C1158834E@sarenet.es> <43345736.3090602@gugol.ru> <20050923215556.GB72838@logik.internal.network> In-Reply-To: <20050923215556.GB72838@logik.internal.network> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanner: exiscan *1EIvdA-000IvF-00*l2YaapjCFtI* (ISBER - Institute for Social, Behavioral, and Economic Research) Cc: freebsd-security@freebsd.org Subject: Re: mounting filesystems with "noexec" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2005 22:03:05 -0000 > With all that has been said so far, what is the actual point of > the noexec flag? it prevents executables from being executed on a specific partition. for instance, you can mount /var with the noexec flag and if you then try to run any binaries (executables) from /var they simply will not execute. root@server[~]% grep 'noexec' /etc/fstab /dev/aacd0s1h /var ufs rw,noexec,nosuid 2 2 root@server[~]% cp /usr/bin/top /var/top root@server[~]% /var/./top /var/./top: Permission denied. -randall -- :// randall s. ehren :// voice 805.893.5632 :// systems administrator :// isber|survey|avss.ucsb.edu :// institute for social, behavioral, and economic research From owner-freebsd-security@FreeBSD.ORG Sat Sep 24 01:02:55 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5AEFC16A41F for ; Sat, 24 Sep 2005 01:02:55 +0000 (GMT) (envelope-from dart@es.net) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0599A43D53 for ; Sat, 24 Sep 2005 01:02:54 +0000 (GMT) (envelope-from dart@es.net) Received: from [198.128.1.31] ([198.128.1.31]) by postal2.es.net (Postal Node 2) with ASMTP (SSL) id IBA74465 for ; Fri, 23 Sep 2005 15:59:13 -0700 Message-ID: <433488C1.5030906@es.net> Date: Fri, 23 Sep 2005 15:59:13 -0700 From: Eli Dart Organization: Energy Sciences Network User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050726) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-security@freebsd.org References: <43332CD7.4070107@romab.com> <726F1E71-D4D9-4C34-848D-868C1158834E@sarenet.es> <43345736.3090602@gugol.ru> <20050923215556.GB72838@logik.internal.network> <43347BC3.7000308@ucsb.edu> In-Reply-To: <43347BC3.7000308@ucsb.edu> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: mounting filesystems with "noexec" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dart@es.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2005 01:02:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 randall s. ehren wrote: >> With all that has been said so far, what is the actual point of >> the noexec flag? > > > it prevents executables from being executed on a specific partition. > > for instance, you can mount /var with the noexec flag and if you then > try to run any binaries (executables) from /var they simply will not > execute. Note that while there may be many ways to circumvent noexec in many circumstances, it still raises the bar. If attempts to execute on a filesystem mounted noexec can be logged (and the logs are sent off-box) you have a chance of seeing something. Also, if the execution is part of an automated tool, noexec can cause the tool to fail. It may not be perfect, but I don't consider it useless. --eli -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFDNIjBLTFEeF+CsrMRAuFAAJ9xnIPezUj/RTir7gggcXyAj5MvdwCdE0On DcSKlSJbn5Q/dVsFvYv4Fuc= =MHif -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Sat Sep 24 07:32:21 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9D5616A41F for ; Sat, 24 Sep 2005 07:32:21 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: from nfishbone.nitro.dk (cpe.atm2-0-71337.0x535ccf26.taanxx2.customer.tele.dk [83.92.207.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53A4E43D4C for ; Sat, 24 Sep 2005 07:32:20 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: from zaphod.nitro.dk (localhost [127.0.0.1]) by nfishbone.nitro.dk (Postfix) with ESMTP id CBA8F61C29; Sat, 24 Sep 2005 09:32:18 +0200 (CEST) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id 6E7BF119EB; Sat, 24 Sep 2005 09:32:20 +0200 (CEST) Date: Sat, 24 Sep 2005 09:32:20 +0200 From: "Simon L. Nielsen" To: markzero Message-ID: <20050924073219.GA854@zaphod.nitro.dk> References: <43332CD7.4070107@romab.com> <726F1E71-D4D9-4C34-848D-868C1158834E@sarenet.es> <43345736.3090602@gugol.ru> <20050923215556.GB72838@logik.internal.network> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: <20050923215556.GB72838@logik.internal.network> User-Agent: Mutt/1.5.10i Cc: freebsd-security@freebsd.org Subject: Re: mounting filesystems with "noexec" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2005 07:32:21 -0000 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2005.09.23 22:55:56 +0100, markzero wrote: > With all that has been said so far, what is the actual point of > the noexec flag?=20 =46rom mount(8) (yes I like quoting the docs. when we have them ;) ): This option is useful for a server that has file systems containing binaries for architectures other than its own. --=20 Simon L. Nielsen --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDNQEDh9pcDSc1mlERAumzAJ0QGIRLfVTxRu6EnXMZRxXcE8ujAwCeLwde 83+9ZuFZKwzO9I8sYRgvzVA= =Xw8B -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- From owner-freebsd-security@FreeBSD.ORG Sat Sep 24 19:11:31 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E9AB16A41F for ; Sat, 24 Sep 2005 19:11:31 +0000 (GMT) (envelope-from carlopmart@gmail.com) Received: from qproxy.gmail.com (qproxy.gmail.com [72.14.204.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD3C743D49 for ; Sat, 24 Sep 2005 19:11:30 +0000 (GMT) (envelope-from carlopmart@gmail.com) Received: by qproxy.gmail.com with SMTP id p36so276367qba for ; Sat, 24 Sep 2005 12:11:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding; b=KPeJQe6zYMPkm1QJJHsfsSpVnS98erfi7lbZSY224KLSlA+YvPiZ5GiTAbk2uFLUnCH7oQvpP7F0F8U139ZJjX+NLP27vRNHzUAWqhHYM1z+KOEMjctht0lHXN1XMv8a96xcXxg4xZFWxIeIFo537wveBmc6dtbtagnkLp8oynQ= Received: by 10.65.133.6 with SMTP id k6mr362166qbn; Sat, 24 Sep 2005 11:09:45 -0700 (PDT) Received: from ?192.168.67.214? ( [80.28.33.119]) by mx.gmail.com with ESMTP id e14sm235024qba.2005.09.24.11.09.43; Sat, 24 Sep 2005 11:09:45 -0700 (PDT) Message-ID: <43359660.2060606@gmail.com> Date: Sat, 24 Sep 2005 20:09:36 +0200 From: "carlopmart@gmail.com" User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050912) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-security Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Encrypt some services with ipsec X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2005 19:11:31 -0000 Hi all, I have two prodction servers with FreeBSD 5.4 (all security patches are applied). They running some services like dns, ssh, http, ftp, etc. But I woukd like to encrypt some services for some hosts with ipsec when it is accessed. For example: - DNS resolution: not encrypted. - DNS replication master-slave: encrypted by ipsec. - Telnet: encrypted by ipsec for some hosts. Deny for the rest. - SSH: not encrypted for some hosts, encryted by ipsec for the rest. - FTP: encrypted by ipsec. - HTTP: encrypted by ipsec. is it possible to encrypt only certains services under ipsec tunnel?? Thank you for your help. -- CL Martinez carlopmart {at} gmail {d0t} com From owner-freebsd-security@FreeBSD.ORG Sat Sep 24 20:33:22 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A799816A41F for ; Sat, 24 Sep 2005 20:33:22 +0000 (GMT) (envelope-from suporte@wahtec.com.br) Received: from galois.wahtec.com.br (galois.wahtec.com.br [200.96.65.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37BC743D48 for ; Sat, 24 Sep 2005 20:33:20 +0000 (GMT) (envelope-from suporte@wahtec.com.br) Received: (qmail 84126 invoked by uid 98); 24 Sep 2005 20:33:18 -0000 Received: from 127.0.0.1 by brasil.intranet (envelope-from , uid 1024) with qmail-scanner-1.24 (f-prot: 4.4.7/3.14.13. spamassassin: 2.63. Clear:RC:1(127.0.0.1):. Processed in 0.10102 secs); 24 Sep 2005 20:33:18 -0000 X-Qmail-Scanner-Mail-From: suporte@wahtec.com.br via brasil.intranet X-Qmail-Scanner: 1.24 (Clear:RC:1(127.0.0.1):. Processed in 0.10102 secs) Received: from unknown (HELO buddyguy) (arisjr@unknown) by unknown with SMTP; 24 Sep 2005 20:33:18 -0000 From: suporte@wahtec.com.br To: freebsd-security@freebsd.org Date: Sat, 24 Sep 2005 20:33:14 +0000 User-Agent: KMail/1.8 References: <20050924120107.11A8416A424@hub.freebsd.org> In-Reply-To: <20050924120107.11A8416A424@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200509242033.15931.suporte@wahtec.com.br> Subject: Re: mounting filesystems with "noexec" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2005 20:33:22 -0000 > > On 2005.09.23 22:55:56 +0100, markzero wrote: > > With all that has been said so far, what is the actual point of > > the noexec flag? > > > >From mount(8) (yes I like quoting the docs. when we have them ;);) ): > > =A0=A0=A0=A0=A0=A0=A0=A0This option is useful for a server that has file = systems > =A0=A0=A0=A0=A0=A0=A0=A0containing binaries for architectures other than = its own. Sorry Simon and others,=20 Where the least privilege principle gone? If there isn't any necessity to h= ave=20 normal or suid binaries on a partition, why enable it? Using it on a data-only partition with a chrooted application does not limi= t=20 any possible damage? Like file upload and execution using an application=20 security flaw could be stopped at some point.=20 Saying one can easily do privilege escalation (like ppl are saying) doesn't= =20 eliminate the need of file permissions and other access policies. Regards, =2D-aristeu