Date: Sun, 7 Jan 2001 18:45:46 -0800 From: "Crist J. Clark" <cjclark@reflexnet.net> To: freebsd-security@freebsd.org Subject: Read-Only Filesystems, mount(2) patch Message-ID: <20010107184546.E95729@rfx-64-6-211-149.users.reflexco>
next in thread | raw e-mail | index | archive | help
I got bored enough while on vacation last week to actually make the
simple hack to prevent changes to mounts at high (>2)
securelevels. The patch is so small I am including it inline,
--- sys/kern/vfs_syscalls.c.orig Sat Dec 16 04:41:58 2000
+++ sys/kern/vfs_syscalls.c Wed Jan 3 00:20:03 2001
@@ -122,6 +122,14 @@
struct nameidata nd;
char fstypename[MFSNAMELEN];
+ /*
+ * Prevent changes in mount properties at securelevel > 1
+ */
+ if (securelevel > 1) {
+ printf("failed mount(2) at securelevel\n");
+ return (EPERM);
+ }
+
if (usermount == 0 && (error = suser(p)))
return (error);
/*
Brilliant, huh? It took me two hours to find mount(2) (once you find
it the location seems obvious of course) and 35 seconds to write the
code.
Now, this breaks some things. This is unavoidable since the whole idea
is to break mount(2) at securelevel. I have played with this
modification with respect to local filesystems and it does what I
want. You can't make changes once the securelevel gets notched up.
However, there may be desired functionality that may be
lost. Potential NFS problems always come to mind, but then I wonder
how much you are worrying about security if you are using NFS. But
_then_ I think of the possibility of locking down the local OS on
"public" workstations where most user data is mounted from a server,
and I could see why the machine would be running at high securelevel
and still be moving NFS mounts around.
There was a fair amount of discussion on the 'Read-Only Filesystems'
thread from two weeks ago, so I think there is some interest in the
topic. Here are some questions/opinions on this subject:
- Is changing the mount(2) code to check securelevel(8) the way to
do this? The controls must of course be in the kernel. mount(2)
seems like the obvious place. But is using kern.securelevel too
granular?
- Is losing the ability to use mount(2) going to really break stuff
that should not be broken?
- If this is too strict, what are the conditions that should be put
on mounts? Examples: Read-write can be changed to read-only, but
not back. nosuid can be turned on, but not off. nodev can be
turned on, but not off. Same deal with noexec. No "new"
filesystems can be mounted, /unless/ mounted nosuid and nodev. And
noexec?
Overall, this is what I was seeking to do, so I probably am not going
to go further with this unless someone has some interesting ideas on
the above thoughts or has some of their own that I have not
considered.
--
Crist J. Clark cjclark@alum.mit.edu
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010107184546.E95729>