Date: Wed, 8 Feb 2017 17:10:52 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= <Trond.Endrestol@fagskolen.gjovik.no> To: Odhiambo Washington <odhiambo@gmail.com> Cc: User Questions <FreeBSD-questions@freebsd.org> Subject: Re: hardening /tmp Message-ID: <alpine.BSF.2.20.1702081705320.97144@mail.fig.ol.no> In-Reply-To: <CAAdA2WNu4ZGQgRP97T6QL%2B%2BM7aNmHQQO6_TYaxmD1G9wcMv8oQ@mail.gmail.com> References: <687643e26aeb858b3b5d9f5693829360.squirrel@webmail.harte-lyne.ca> <alpine.BSF.2.20.1702081640410.97144@mail.fig.ol.no> <CAAdA2WNu4ZGQgRP97T6QL%2B%2BM7aNmHQQO6_TYaxmD1G9wcMv8oQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 8 Feb 2017 18:58+0300, Odhiambo Washington wrote: > On 8 February 2017 at 18:43, Trond Endrestøl <Trond.Endrestol@fagskolen. > gjovik.no> wrote: > > > On Wed, 8 Feb 2017 10:22-0500, James B. Byrne via freebsd-questions wrote: > > > > > How do most people handle hardening /tmp and /var/tmp on FreeBSD? I > > > can get rid of /tmp from the file system and then simply mount it as a > > > tmpfs in /etc/fstab. > > > > > > tmpfs /tmp tmpfs rw,nosuid,noexec,mode=01777 0 0 > > > > > > However, /var/tmp is supposed to survive across reboots so how is this > > > handled? > > > > If ZFS is an option, then create a separate dataset/filesystem for > > /var/tmp, and set its quota to something sensible. > > > > If UFS is your (only) option, then create a separate partition of > > reasonable size and mount that as your /var/tmp. > > > > You can also consider a filebacked mfs of a certain size for your > > /var/tmp. > > What are we mitigating? A situation where some bad guy fills /tmp and > collapses the system/ Or a situation where a bad guy manages to access our > /tmp and uses it to launch his scripts? > I remember this hardening subject from years back, so I googled "freebsd > security hardeng" and found so much being discussed, including even a port > that was specifically made to achieve the same, as you can read from > https://linux-audit.com/freebsd-hardening-lynis/ One scenario might include user access to said system(s), where some of the (ab)users might hoard the available disk space. This scenario also includes quota being used for the regular home directories. Unix was originally created for small teams of developers, and such bunches of people are far easier to handle than a whole college department full of (ab)users. I'm sorry for punching up the language and for hijacking the thread. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-questions@freebsd.org Wed Feb 8 17:19:58 2017 Return-Path: <owner-freebsd-questions@freebsd.org> Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5F75CD659D for <freebsd-questions@mailman.ysv.freebsd.org>; Wed, 8 Feb 2017 17:19:58 +0000 (UTC) (envelope-from matt.xtaz@gmail.com) Received: from mail-wr0-x244.google.com (mail-wr0-x244.google.com [IPv6:2a00:1450:400c:c0c::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4A0F512DB for <FreeBSD-questions@freebsd.org>; Wed, 8 Feb 2017 17:19:58 +0000 (UTC) (envelope-from matt.xtaz@gmail.com) Received: by mail-wr0-x244.google.com with SMTP id k90so9306326wrc.3 for <FreeBSD-questions@freebsd.org>; Wed, 08 Feb 2017 09:19:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=9iroc91doXQUuNVvwWQmkzxvzmBCmIaQhounoAKMpNU=; b=ba97VgPUE8zfMC2B/ujZ8RIYcUsT4MRSkc/CW26IFcVEnWjcxhtuNry6/U7vF6gszG hf9+X6qQr97g/p4lPaSoDxLiYSPKjXI/USO1omuoiXbcMRfWgb4dYXosmIj7H+2ACAw5 F1ZOIen8Qj0OJ3QAPc6mBAEiVt4aMrND8xEH01jEKuQ9n9WK/+2+Zvdv1+oiBRe8vMSD fY17lGV87SAuhpLBMYXFw1mH2G65GiUFkMAp1OBqpdbiO07TXYmugzaztQq0P95eo/so 6oivDjZ73y8BQRqt5ZBzaWTNpaCPUFetIH+M72/j8OP7KR87ry4RxGU0Pp+M5oJaq6Qy kBAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=9iroc91doXQUuNVvwWQmkzxvzmBCmIaQhounoAKMpNU=; b=Ws3MCTaoQiCPVxtu9TPrgc1jxzrEB4iIhWlgrZ+AL9ibF6/hcbfGKsA6xVPy16xjx2 yUw3BUn4aShlFtQ9yZsu26UxIvzh1oj3eVS3HzDomtqaPKikraZ2sMA8LBjTnt9tgLDG gB4ki3fwesuz9ksVsvWlv2H7ZqF7XGGzjkvhQi+QnG3PIDaQfcxZuqkQjZ6gCxQhr2yp bVK1w7TTFErhWCFox56QnxKMdL9rLi83IFHE1PNpIZXkn7nr+PBsogWrjDtAjD8aOVuB rtPEvBA3jtyv2OTZU8rT1xDnuP9gPK45T3PMXcNh3haFcbJyUirvfWhyGHGizng2fdy4 9Z5A== X-Gm-Message-State: AIkVDXJKRk8VOQrq+R/xdM8seJdUi+uADnY6pQrFc0aa+a8dEJn29pL28mdZXhgScaOFag== X-Received: by 10.223.167.66 with SMTP id e2mr19641696wrd.48.1486574395921; Wed, 08 Feb 2017 09:19:55 -0800 (PST) Received: from gmail.com (tao.xtaz.uk. [2001:8b0:fe33::10]) by smtp.gmail.com with ESMTPSA id w69sm4368071wmw.22.2017.02.08.09.19.55 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 08 Feb 2017 09:19:55 -0800 (PST) Date: Wed, 8 Feb 2017 17:19:53 +0000 From: Matt Smith <matt.xtaz@gmail.com> To: byrnejb@harte-lyne.ca Cc: FreeBSD-questions@freebsd.org Subject: Re: hardening /tmp Message-ID: <20170208171953.GB68602@gmail.com> Mail-Followup-To: Matt Smith <matt.xtaz@gmail.com>, byrnejb@harte-lyne.ca, FreeBSD-questions@freebsd.org References: <687643e26aeb858b3b5d9f5693829360.squirrel@webmail.harte-lyne.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <687643e26aeb858b3b5d9f5693829360.squirrel@webmail.harte-lyne.ca> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions <freebsd-questions.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-questions>, <mailto:freebsd-questions-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-questions/>; List-Post: <mailto:freebsd-questions@freebsd.org> List-Help: <mailto:freebsd-questions-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-questions>, <mailto:freebsd-questions-request@freebsd.org?subject=subscribe> X-List-Received-Date: Wed, 08 Feb 2017 17:19:58 -0000 On Feb 08 10:22, James B. Byrne via freebsd-questions wrote: >How do most people handle hardening /tmp and /var/tmp on FreeBSD? I >can get rid of /tmp from the file system and then simply mount it as a >tmpfs in /etc/fstab. > >tmpfs /tmp tmpfs rw,nosuid,noexec,mode=01777 0 0 > >However, /var/tmp is supposed to survive across reboots so how is this >handled? > I tried exactly this along with also doing it to /var/tmp and decided to back out my changes. If you mount /tmp noexec you will find that make installworld breaks. tmpfs doesn't allow you to change mount options so you have to unmount it. Unmounting it kills tmux or screen which I use. It's just hassle! And /var/tmp has vi.recover in it which is created on boot by /etc/rc.d/virecover but it creates this before the tmpfs is mounted over the top of it so the result is that it doesn't exist. I don't know what the effects of that are, especially as I use vim but still it annoyed me. -- Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.20.1702081705320.97144>