Date: 18 Oct 1999 16:49:00 +0200 From: Dag-Erling Smorgrav <des@flood.ping.uio.no> To: Jacques Vidrine <n@nectar.com> Cc: freebsd-arch@freebsd.org Subject: Re: kern.securelevel and X Message-ID: <xzp90503esj.fsf@flood.ping.uio.no> In-Reply-To: Jacques Vidrine's message of "Mon, 18 Oct 1999 09:26:33 -0500" References: <XFMail.991015111802.shelton@sentry.granch.ru> <Pine.LNX.4.05.9910150036170.5339-100000@jason.argos.org> <14343.23571.679909.243732@blm30.IRO.UMontreal.CA> <19991017012750.A812@fever.semiotek.com> <380A1E2C.CCA326F5@gorean.org> <19991018024704.A512@semiotek.com> <xzpyad12jd7.fsf@flood.ping.uio.no> <19991018043039.B1711@semiotek.com> <xzpso392gj0.fsf@flood.ping.uio.no> <19991018142633.D1DDB1DA3@bone.nectar.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jacques Vidrine <n@nectar.com> writes: > Further, I feel like most (all) calls to suser or what have you in > the top of the kernel could be covered if we made the granularity == > syscall. This would break some abstraction, but if our hypothetical > new suser or sec_permitted ``knew'' it was being called in the top of > the kernel and ``knew'' what the current syscall was, our operations > could just be table lookups. And especially for suser, we could > tweak securelevel and jail stuff without having to modify the call > to suser. With all due respect, *yuck* :) What EE suggested was to define a new SYSCTL macro to make defining new security sysctls trivial. You'd do something like this: static int sec_syscall_mount = 1; SYSCTL_SECURITY(mount, &sec_syscall_mount, "Allow mounting filesystems"); int mount(p, uap) /* ... */ { /* ... */ if (usermount == 0 && (error = suser(p))) return (error); if (sec_syscall_mount) return (EPERM); /* ... */ } This is *very* rough; I don't think I'd actually use an explicitly defined int like above; I'd rather use some kind of automagically- defined symbolic constant and a function call / macro for checking if it's set or not. This demonstrates the general idea, though; the rest is implementation details :) The sysctl knob would be named ``kern.security.mount'' or something, and be one-way; its initial value would be 1, and you'd be allowed to set it to 0 but not set it back to 1. The current sysctl_kern_securelevel() would be rewritten to twiddle the appropriate knobs, so that setting kern.securelevel would still have the expected effect. Going the other way (translating security settings into a meaningful kern.securelevel value) is not as trivial, though, so userland programs which rely on *checking* the value of kern.securelevel (as oppsoed to just *setting* it) may break. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzp90503esj.fsf>