Date: Sat, 19 Dec 1998 14:21:14 -0800 From: Mike Smith <mike@smith.net.au> To: Don Lewis <Don.Lewis@tsc.tdk.com> Cc: current@FreeBSD.ORG Subject: Re: adding policy tuning knobs to my F_SETOWN/SIGIO/SIGURG enhancements Message-ID: <199812192221.OAA00695@dingo.cdrom.com> In-Reply-To: Your message of "Sat, 19 Dec 1998 00:56:19 PST." <199812190856.AAA11948@salsa.gv.tsc.tdk.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I'm not sure that we want to open something like this to general
manipulation - it provides one more way for someone to make assumptions
about the behaviour of the system. If the "secure" mode isn't
ridiculously onerous, I think that it's perhaps better to leave that
the only mode that's supported, ie. if someone wants to change its
behaviour they need to be aware of the consequences.
> I'm still looking for comments on this. Eivind was the only one who
> spoke up when I posted it to -hackers. He was in favor of leaving
> the policy compiled in.
>
> I'd like to commit this or something like it in the next couple of days.
>
> The questions still stand.
>
>
> ===== Forwarded from -hackers ==============
>
> My previous security enhancements to the F_SETOWN/SIGIO/SIGURG in the 3.0
> kernel code made some policy decisions that were hard-wired into the code
> but were commented in case someone needed to change them. I've decided
> that would be good to allow the security policy to be tuned using some
> sysctl knobs. The attached patch adds two policy adjustments,
> kern.security.setown_restrict, and kern.security.async_io_cred_check,
> which can be used to limit the process or process group that can be
> specified to F_SETOWN, and whether credentials should be checked before
> delivering the signals.
>
> Questions:
>
> Should these variables live under kern.security, directly under
> kern, or elsewhere?
>
> I also want to add some other security related tunables in other
> parts of the kernel. Assuming they should also live under
> kern.security, where should
> "SYSCTL_NODE(_kern, OID_AUTO, security, ...)" live? I've already
> got kern.security sysctl variables in two different files ...
>
> Any other comments on this patch are welcome.
>
>
> --- kern_descrip.c.orig Wed Nov 11 03:08:32 1998
> +++ kern_descrip.c Sat Dec 12 23:39:50 1998
> @@ -392,7 +392,24 @@
> *
> * After permission checking, add a sigio structure to the sigio list for
> * the process or process group.
> + *
> + * The setown_restrict variable sets a policy which may restrict the allowable
> + * process/group argument for F_SETOWN/FIOSETOWN. An argument of 0 is
> + * always allowed.
> + * 0 - There are no restrictions, any existing process or process group
> + * may be specified.
> + * 1 - Any process or process group specified must belong to the same
> + * session as the current process.
> + * 2 - Only the current process group or a process in the current process
> + * group may be specified. This is the default.
> + * 3 - Only the current process may be specified.
> + *
> */
> +static int setown_restrict = 2;
> +SYSCTL_NODE(_kern, OID_AUTO, security, CTLFLAG_RW, 0, "");
> +SYSCTL_INT(_kern_security, OID_AUTO, setown_restrict,
> + CTLFLAG_RW|CTLFLAG_SECURE, &setown_restrict, 0, "");
> +
> int
> fsetown(pgid, sigiop)
> pid_t pgid;
> @@ -411,30 +428,20 @@
> proc = pfind(pgid);
> if (proc == NULL)
> return (ESRCH);
> - /*
> - * Policy - Don't allow a process to FSETOWN a process
> - * in another session.
> - *
> - * Remove this test to allow maximum flexibility or
> - * restrict FSETOWN to the current process or process
> - * group for maximum safety.
> - */
> - else if (proc->p_session != curproc->p_session)
> + if (setown_restrict > 2 && proc != curproc ||
> + setown_restrict > 1 && proc->p_pgrp != curproc->p_pgrp ||
> + setown_restrict > 0 &&
> + proc->p_session != curproc->p_session)
> return (EPERM);
> pgrp = NULL;
> } else /* if (pgid < 0) */ {
> pgrp = pgfind(-pgid);
> if (pgrp == NULL)
> return (ESRCH);
> - /*
> - * Policy - Don't allow a process to FSETOWN a process
> - * in another session.
> - *
> - * Remove this test to allow maximum flexibility or
> - * restrict FSETOWN to the current process or process
> - * group for maximum safety.
> - */
> - else if (pgrp->pg_session != curproc->p_session)
> + if (setown_restrict > 2 ||
> + setown_restrict > 1 && pgrp != curproc->p_pgrp ||
> + setown_restrict > 0 &&
> + pgrp->pg_session != curproc->p_session)
> return (EPERM);
> proc = NULL;
> }
> --- kern_sig.c.orig Tue Dec 8 20:40:50 1998
> +++ kern_sig.c Sun Dec 13 00:10:50 1998
> @@ -1358,9 +1358,16 @@
> }
>
> /*
> - * Send a signal to a SIGIO or SIGURG to a process or process group using
> - * stored credentials rather than those of the current process.
> + * Send a SIGIO or SIGURG signal to a process or process group in
> + * response to an I/O event.
> + *
> + * If async_io_cred_check is nonzero, the stored credentials from
> + * the process that did the F_SETOWN/FIOSETOWN are first checked
> + * to see if it is permissible to send the signal.
> */
> +static int async_io_cred_check = 1;
> +SYSCTL_INT(_kern_security, OID_AUTO, async_io_cred_check,
> + CTLFLAG_RW|CTLFLAG_SECURE, &async_io_cred_check, 0, "");
> void
> pgsigio(sigio, signum, checkctty)
> struct sigio *sigio;
> @@ -1370,15 +1377,17 @@
> return;
>
> if (sigio->sio_pgid > 0) {
> - if (CANSIGIO(sigio->sio_ruid, sigio->sio_ucred,
> - sigio->sio_proc))
> + if (!async_io_cred_check ||
> + CANSIGIO(sigio->sio_ruid, sigio->sio_ucred,
> + sigio->sio_proc))
> psignal(sigio->sio_proc, signum);
> } else if (sigio->sio_pgid < 0) {
> struct proc *p;
>
> for (p = sigio->sio_pgrp->pg_members.lh_first; p != NULL;
> p = p->p_pglist.le_next)
> - if (CANSIGIO(sigio->sio_ruid, sigio->sio_ucred, p) &&
> + if ((!async_io_cred_check ||
> + CANSIGIO(sigio->sio_ruid, sigio->sio_ucred, p)) &&
> (checkctty == 0 || (p->p_flag & P_CONTROLT)))
> psignal(p, signum);
> }
>
> ===========================================
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message
>
--
\\ Sometimes you're ahead, \\ Mike Smith
\\ sometimes you're behind. \\ mike@smith.net.au
\\ The race is long, and in the \\ msmith@freebsd.org
\\ end it's only with yourself. \\ msmith@cdrom.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812192221.OAA00695>