Date: Mon, 16 Nov 1998 11:41:04 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Warner Losh <imp@village.org>, Andre Albsmeier <andre.albsmeier@mchp.siemens.de>, Matthew Dillon <dillon@apollo.backplane.com>, freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? Message-ID: <199811161941.LAA21747@apollo.backplane.com> References: <19981116081640.A2304@internal> <19981116072937.E969@internal> <19981115192224.A29686@internal> <19981115161548.A23869@internal> <199811151758.JAA15108@apollo.backplane.com> <19981115192224.A29686@internal> <199811152210.PAA01604@harmony.village.org> <19981116072937.E969@int <199811161842.LAA05020@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Ok, here is a proposal:
(1)
Add a 'kmem' and 'tty' dummy user to /usr/src/etc/master.passwd.
Unfortunately, the operator uid is already using 2 (why it didn't
use 5 I'll never know), so give the kmem user uid 5 and the tty
user uid 4 (same as their groups except for the operator<>kmem
flip).
Is there an ANSI or POSIX standard here that we have to use instead
of just guessing?
(2)
Change identd and ntalkd entries in inetd.conf to run ntalkd tty:tty
and identd kmem:kmem.
(3)
Add an lp user and an lp group (what uid/gid ?).
Adjust lpr source to disallow -s if lpd is running secure.
Adjust lpd to chown itself to user/group lpd on startup after binding
its socket. Some additional work may be required to make sure all
the various lpd/lpc/other interactions still work properly.
Adjust mtree and MAKEDEV as appropriate to give printer spool and
printer devices appropriate user/group perms
(4)
Add a simple inherited capability resource, operating as a bitmask,
using two resources. Don't try to do anything fancy.
RLIMIT_MYCAP my capabilities (bitmask: current, allowed)
RLIMIT_INHCAP capabilities inheritable by subprocesses
(bitmask: current, allowed)
(subprocess inherits MYCAP = INHCAP & MYCAP
for both rlim_cur and rlim_max, and inherits
INHCAP directly).
So, for example, you could give a program the ability to turn on
certain capabilities but prevent the program from being able to
pass some or all of those capabilities to a subprocess (fork or exec).
You can give a program permission to use certain capabilities by
setting rlim_max but require it to turn them on itself by setting
rlim_cur. rlim_cur/rlim_max would operate as a bitmask rather then
a value/maximum.
Only root would be allowed to arbitrarily modify capabilities,
the idea being that root is more secure as other programs stop being
run as it. So, for example, you could still start named, sendmail,
lpd, and so forth as root, but they would immediately set their
capabilities and become someone else.
Any call to setuid() clears all capabilities and removes permission
to set them again.
We define several capabilities right off the bat:
RCAPF_LOWPORT allow binding to low ports
RCAPF_GIVEAWAY allow chowning a file to another
user (any uid in the kern.cap.uidlow
through kern.cap.uidhigh range). ala
SysV
RCAPF_SETTIME allow the process to set and/or adjust
the time (so xntpd does not have to run
as root).
(5)
Use RCAPF_SETTIME to fix xntpd
Use TCAPF_LOWPORT to fix xntpd, lpd, bind, sendmail, and possibly
others. sendmail might still have to be run by root by default for
program pipes, but that's a different problem that I presume
Eric Allman will work on at some point (such functionality should
really be moved into mail.local, IMHO, I'll email Eric and see
what he has to say about it).
(6)
... and so on.
-Matt
:Warner
:
Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet
Communications & God knows what else.
<dillon@backplane.com> (Please include original email in any response)
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?199811161941.LAA21747>