From owner-freebsd-questions@freebsd.org Fri Jun 2 19:33:37 2017 Return-Path: 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 3D495AFA1F2 for ; Fri, 2 Jun 2017 19:33:37 +0000 (UTC) (envelope-from tjg@ucsc.edu) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 BA5D274B8D for ; Fri, 2 Jun 2017 19:33:36 +0000 (UTC) (envelope-from tjg@ucsc.edu) Received: by mail-lf0-x22d.google.com with SMTP id h4so48113788lfj.3 for ; Fri, 02 Jun 2017 12:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucsc.edu; s=ucsc-google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/hG+iAF6EWmh8CwFN1GB4Fz3+U2LyMWWpUVzHyDKDgc=; b=GldTBWDFPyfzEayRYvT0prBzLUctqOZqLaVNRZxwX+yeXqmUKtm7ddNMRku56TuTlt wxy1FwTgu10CJGWDGkDnDF1DCdIhu7JtnEl4pqgJoGfB2pT8ZVS5ecDYuZVVGqAxsjPO VmGn2Y3RDW9bIQZ5Mcevy/KNc9lTfwFyfu7wg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/hG+iAF6EWmh8CwFN1GB4Fz3+U2LyMWWpUVzHyDKDgc=; b=h/BL2iSUwdUC31Va+QiQWB5XatjJvrvEU1P+e/aLIxCvFLbAJFKbEtInpvJL5hI5rd O6K9TW4mY8eYegBFSKInzjBVfZTxTiFN4iL/0KFYAhU2vPe5VfkbBF4XvFDAfp7l2AwQ 15R/J5ZaYxi5sQwU6fF1J9boaB9sHFiycBAaB+BlDEY8hx3Eh7MmvlnRl3kwzV4tH6Pi azgKYSNCVAMBgXfhJeLPzd3GofqJI9CF8vflMpHb3+mU/ytKKb3rbSH5Mid2MJwMmFYf ZGo1hW/QF5wWf7yDp+/4fdZr3Arecix+dvcyNXjezmRM4cBNY3SI36BK1YEjjU7kAMFj SM4w== X-Gm-Message-State: AODbwcBDhhOUU8jpI0b7URs9xSqHkDNULGr26K0LJ9xy6txLbsxFlS0U MtDH8UylFSkJtcfk9UCnkKdMnZuDCLH8 X-Received: by 10.46.81.89 with SMTP id b25mr2777810lje.33.1496432014904; Fri, 02 Jun 2017 12:33:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.16.31 with HTTP; Fri, 2 Jun 2017 12:33:34 -0700 (PDT) In-Reply-To: References: From: Tim Gustafson Date: Fri, 2 Jun 2017 12:33:34 -0700 Message-ID: Subject: Re: Excluding File Systems from 100.chksetuid and 110.neggrpperm To: Adam Vande More Cc: FreeBSD Questions Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 19:33:37 -0000 >> https://forums.freebsd.org/threads/31846/ > That thread mentions this posting which contains responses as to why it > likely was never pursued further: > > https://docs.freebsd.org/cgi/getmsg.cgi?fetch=275969+0+/usr/local/www/mailindex/archive/2012/freebsd-stable/20120506.freebsd-stable Sorry, I think I'm missing something. I don't see anything in that thread that suggests why it wouldn't be implemented. There's some chatter about not excluding all ZFS filesystems, but I'm not asking about that. I'm asking about excluding individual filesystems. In the original post I shared, the suggested patch included the ability to exclude by mount point, rather than by file system type. My desired settings would be: daily_status_security_chksetuid_fs_ignore="/export" daily_status_security_neggrpperm_fs_ignore="/export" As these are just NFS servers, users never log into them and can't run processes on them. I could mount them locally with nosuid and noexec but then it's not clear to me how that would affect NFS clients that mount these file systems, but I think setting nosuid and noexec on the server wouldn't have any effect on the NFS clients. Also, there are certainly legitimate suid and non-suid binaries in those file systems that need to be run on the clients that mount them. I suppose if these processes should really run for security purposes, it would be better to have them run on a particular day. For example, having them start late on Friday night or very early Saturday morning would avoid our heaviest workload periods. But that also seems to not be an option, unless there is something fancy I can do in periodic.conf that's not immediately apparent to me, or by hacking files in /etc/periodic, which I'd rather not do if I can avoid it. -- Tim Gustafson BSOE Computing Director tjg@ucsc.edu 831-459-5354 Baskin Engineering, Room 313A To request BSOE IT support, please visit https://support.soe.ucsc.edu/ or send e-mail to help@soe.ucsc.edu.