Date: Thu, 31 May 2001 21:29:46 +0200 From: Patrick Atamaniuk <patrick@atabersk.de> To: karsten@rohrbach.de Cc: Dan Pelleg <dpelleg+bsd@cs.cmu.edu>, freebsd-security@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: remounts (was: Re: adding "noschg" to ssh and friends) Message-ID: <20010531212946.B18049@mail.atabersk.de> In-Reply-To: <3B16884E.FC7A1E89@globalstar.com>; from crist.clark@globalstar.com on Thu, May 31, 2001 at 11:07:10AM -0700 References: <20010531123020.6044537B422@hub.freebsd.org> <3B1686B2.5693822B@globalstar.com> <3B16884E.FC7A1E89@globalstar.com>
next in thread | previous in thread | raw e-mail | index | archive | help
almost identical code i am running on a firewall with no problems, only difference
(besides no logging) is that unmount suffers from the same problem.
beware, the diff is old, may not patch in easily.
init(8) states :
...
2 Highly secure mode - same as secure mode, plus disks may not be
opened for writing (except by mount(2)) whether mounted or not.
This level precludes tampering with filesystems by unmounting them,
but also inhibits running newfs(8) while the system is multi-user.
...
so i consider unmounting at securelevel 2 not being prohibited not
as a bug but i disagree on the statement that this would be higly secure.
I dont want to have my firewall filesystems unmounted, being read only or
read write, from somewhere else than the local console.
IMVHO the securelevel system is not generic enough, a capability system
(i.e. kernel variables) defining what is allowed and what is forbidden
with a freeze of this definition by raising the securelevel to 1 or
higher could help out. (defaulting to current behaviour it most likely
would not break anything)
to the remarks from Crist (please follow link below):
- controlling the mount in mount(2) in the kernel is the most generic
place, there's no way around it.
kern.securelevel is imvho not granular enough to end all this
selfmade patches and featurerequests.
- breaking stuff by raising the securelevel is the whole idea, i agree
with Crist.
- Brining fine grain and conditions into the game this will be much
work. Allowing transitions from insecure to secure (remount ro) would
go da'cor with the system immutable flag behaviour, but even that
should be controllable (before raising the securelevel actually), since
there may be conditions where i need my /usr fs readwrite to operate
correctly. (not speaking of /var or others)
anyhow, here (my old) patch including unmount. The interested reader may
himself include logging of the event.
------ snip -----
--- 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);
------ snip -----
Crist Clark(crist.clark@globalstar.com)@2001.05.31 11:07:10 +0000:
> Crist Clark wrote:
>
> [snip]
>
> Oops, the actual patch came shortly after,
>
> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=31106+0+archive/2001/freebsd-security/20010114.freebsd-security
>
--
regards,
Patrick
----------------------------------------------------
Patrick Atamaniuk patrick@atabersk.de
----------------------------------------------------
//my code breaks everything including your cat.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010531212946.B18049>