Date: Tue, 25 Feb 2003 17:01:56 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: Martin Blapp <mb@imp.ch> Cc: John Baldwin <jhb@FreeBSD.org>, Bob Bishop <rb@gid.co.uk>, re@FreeBSD.org, hackers@FreeBSD.org Subject: Re: Jdk13/14 still hangs in 4.8 Prerelease. Outstanding Fix need (fwd) Message-ID: <Pine.NEB.3.96L.1030225165857.73285B-100000@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
Per Martin's request, I'm forwarding this response to the broader group
involved in this thread. Basically, I think broadening the scope of
processes permitted to make the scheduler call is fine, but you don't want
to use the CANSIGNAL() code that's currently present for several reasons.
The simplist solution might be to only allow the scheduler change if the
requesting process is targetting itself.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org Network Associates Laboratories
---------- Forwarded message ----------
Date: Tue, 25 Feb 2003 12:53:53 -0500 (EST)
From: Robert Watson <rwatson@FreeBSD.org>
To: Martin Blapp <mb@imp.ch>
Subject: Re: Jdk13/14 still hangs in 4.8 Prerelease. Outstanding Fix need (fwd)
On Tue, 25 Feb 2003, Martin Blapp wrote:
> Basically, it changes p31b_proc() to not always return an error for
> non-root. If rwaston@ signs off on the security implications (should be
> minimal, basically means that you can change your own scheduling params
> and can change the params of other processes you own) then I would
> prefer this patch.
Hmm. I think the check there is a bit on the unsafe side, that could be
why it was disabled. Basically, it permits the scheduler change in the
following four circumstances:
(0) Superuser always wins
(1) Subject real uid is object real uid
E.g., any process I should randomly start or own
(2) Subject effective uid is object real uid
If a tool is temporarily switched to my uid to exercise my
privileges, sounds OK.
(3) Subject real uid is object effective uid (uh oh)
(4) Subject effective uid is object effective uid (uh oh)
The reason (3) and (4) are problems is that they affect daemons
temporarily switching to a user's privileges to carry out a task -- such
as mail delivery, or a userland NFS server or the like. It could be that
these are poor handling of the loopback process case, wherein a process
can always modify its own scheduling. Take a look at p_cansched() in 5.x
for a bit more what I think the check should be. In summary, the rules
are:
(0) You can always reschedule the current process.
(1) If you're in a different jail, deny.
(2) Optionally call out to MAC.
(3) If the "seeotheruids" support says you can't see the other process,
you can't reschedule it either, regardless of uids.
(4) If the real uids are the same, it's OK -- i.e., any arbitrary shell
process (setuid or otherwise).
(5) If the subject effective uid is the same as the object real uid -- if
temporarily adopting a user's privileges, we can reschedule the
processes they own.
(6) Superuser always wins (subject to 0, 1, 2, 3).
(7) Deny
> I don't know why the check was turned off. The entire #if 0 / #else /
> #endif seems to have been around since revision 1.1.
It's probably because whoever wrote it realized that it was moderately
suspect. I would oppose simply enabling the current CANSIGNAL check -- it
has serious problems. On the other hand, putting in a refined check
sounds reasonable and I'd be happy to review such a patch. Although the
code from 5.x won't instantly work with 4.x without substantial
modification, it might make a good starting point.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org Network Associates Laboratories
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1030225165857.73285B-100000>