From nobody@FreeBSD.ORG  Thu Oct 19 23:16:12 2000
Return-Path: <nobody@FreeBSD.ORG>
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id 7299D37B4E5; Thu, 19 Oct 2000 23:16:11 -0700 (PDT)
Message-Id: <20001020061611.7299D37B4E5@hub.freebsd.org>
Date: Thu, 19 Oct 2000 23:16:11 -0700 (PDT)
From: patrick@atamaniuk.de
Sender: nobody@FreeBSD.ORG
To: freebsd-gnats-submit@FreeBSD.org
Subject: securelevel does not affect mount
X-Send-Pr-Version: www-1.0

>Number:         22142
>Category:       kern
>Synopsis:       securelevel does not affect mount
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    linimon
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Thu Oct 19 23:20:01 PDT 2000
>Closed-Date:    Sun Jun 18 21:16:37 GMT 2006
>Last-Modified:  Sun Jun 18 21:16:37 GMT 2006
>Originator:     Patrick Atamaniuk
>Release:        4.1/4.1.1/5.0
>Organization:
Nacamar/World Online
>Environment:
FreeBSD schweinebilder.dangerzone.nacamar.de 4.1.1-STABLE FreeBSD 4.1.1-STABLE #2: Tue Oct  3 18:17:00 CEST 2000     root@schweinebilder.dangerzone.nacamar.de:/usr/src/sys/compile/S  i386

>Description:
Securelevel should be able to restrict mounting/remounting of filesystems
if raised above a certain level in order to secure ro-mounted filesystems
>How-To-Repeat:
increase securelevel to any value, remount any fs ro->rw works
>Fix:
#in function mount and unmount in vfs_syscalls:
#

--- kern/vfs_syscalls.c.orig    Thu Sep 28 23:22:42 2000
+++ kern/vfs_syscalls.c Thu Sep 28 23:28:54 2000
@@ -120,6 +120,9 @@
        struct nameidata nd;
        char fstypename[MFSNAMELEN];

+       if (securelevel > 1)
+               return EPERM;
+
        if (usermount == 0 && (error = suser(p)))
                return (error);
        /*
@@ -410,6 +413,9 @@
        struct mount *mp;
        int error;
        struct nameidata nd;
+
+       if (securelevel > 1)
+               return EPERM;

        NDINIT(&nd, LOOKUP, FOLLOW | LOCKLEAF, UIO_USERSPACE,
            SCARG(uap, path), p);


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-security 
Responsible-Changed-By: johan 
Responsible-Changed-When: Thu Aug 22 18:41:46 PDT 2002 
Responsible-Changed-Why:  
Lets get -security's opinion about this.  

http://www.freebsd.org/cgi/query-pr.cgi?pr=22142 

From: Johan Karlsson <johan@freebsd.org>
To: bug-followup@freebsd.org
Cc:  
Subject: Fwd: Re: kern/22142: securelevel does not affect mount
Date: Fri, 23 Aug 2002 15:35:07 +0200

 Attach to audit-trail.
 
 ----- Forwarded message from Lupe Christoph <lupe@lupe-christoph.de> -----
 
 From: lupe@lupe-christoph.de (Lupe Christoph)
 To: Jan Srzednicki <winfried@student.uci.agh.edu.pl>
 Cc: Johan Karlsson <johan@FreeBSD.org>, freebsd-bugs@FreeBSD.org,
    freebsd-security@FreeBSD.org
 Subject: Re: kern/22142: securelevel does not affect mount
 Date: Fri, 23 Aug 2002 12:24:02 +0200
 
 On Friday, 2002-08-23 at 09:43:15 +0200, Jan Srzednicki wrote:
 > On Thu, 22 Aug 2002, Johan Karlsson wrote:
 
 > > Synopsis: securelevel does not affect mount
 
 > > Responsible-Changed-From-To: freebsd-bugs->freebsd-security
 > > Responsible-Changed-By: johan
 > > Responsible-Changed-When: Thu Aug 22 18:41:46 PDT 2002
 > > Responsible-Changed-Why:
 > > 	Lets get -security's opinion about this.
 
 > > http://www.freebsd.org/cgi/query-pr.cgi?pr=22142
 
 > I'm afraid changin securelevel's behaviour would break some system schemes
 > out there, which is rather unwanted thing for -STABLE. One thing we can do
 > is to wait for MACs in -CURRENT. Maybe a better solution is to add another
 > sysctl just form mount? Like kern.mount_disabled, which, when set to 1,
 > cannot be reverted back.
 
 It would break my system disk cloning scheme. Currently I mount the
 cloning targets, rsync the live copy, and umount the clones. That way,
 they will not need fsck'ing when I need them. NO big thing, though.
 But on a different (Linux) machine, I write dumps to a Zip drive.
 The medium is umounted and ejected when it's full, to be replaced
 by the alternate medium.
 
 So I agree a finer grained control is need. Preferably even tunable
 per device, allowing the Zip drive to be mounted/umounted, but no other
 device.
 
 I haven't looked at -CURRENT at all. How fine grained are those MACs?
 (Excuse me for not having the time right now to read up on them.)
 
 Lupe Christoph
 -- 
 | lupe@lupe-christoph.de       |           http://www.lupe-christoph.de/ |
 | Big Misunderstandings #6398: The Titanic was not supposed to be        |
 | unsinkable. The designer had a speech impediment. He said: "I have     |
 | thith great unthinkable conthept ..."                                  |
 
 ----- End forwarded message -----
 
 -- 
 Johan Karlsson		mailto:johan@FreeBSD.org
Responsible-Changed-From-To: freebsd-security->security 
Responsible-Changed-By: johan 
Responsible-Changed-When: Sat Aug 24 19:04:48 PDT 2002 
Responsible-Changed-Why:  
Use short names for mailing list to make searches    
using the web query form work with the shown responsible. 

This also makes open PR show up in the summery mail. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=22142 
Responsible-Changed-From-To: security->cjc 
Responsible-Changed-By: cjc 
Responsible-Changed-When: Sun Aug 25 00:02:34 PDT 2002 
Responsible-Changed-Why:  
I'll take it for two reasons: 

1) I went through this same discussion some time ago. I'll look at a 
new knob or kernel config setting to enable this behavior. 

2) Please do not assign PRs to "security" or "freebsd-security." 
Freebsd-security gets PR summaries because of a bug (and I just sent 
peter a patch to fix it). Yes, some lists for developers can be 
assigned PRs, but freebsd-security is not a developers list. It serves 
a wider audience. And the SNR is low enough without lots of PR 
threads. If you want to CC or forward a PR to freebsd-security, OK, 
but don't assign it to the list. If you want to assign 
security-related PRs to a group of developers, assign them to 
security-officer. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=22142 
State-Changed-From-To: open->feedback 
State-Changed-By: linimon 
State-Changed-When: Mon Apr 3 01:29:28 UTC 2006 
State-Changed-Why:  
Is this still a problem in current versions on FreeBSD? 


Responsible-Changed-From-To: cjc->linimon 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Mon Apr 3 01:29:28 UTC 2006 
Responsible-Changed-Why:  
Reset PR assigned to inactive committer who has not responded to email. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=22142 
State-Changed-From-To: feedback->closed 
State-Changed-By: linimon 
State-Changed-When: Sun Jun 18 21:16:10 UTC 2006 
State-Changed-Why:  
Feedback timeout (> 2 months). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=22142 
>Unformatted:
