two questions
Stephen Smalley
sds at tycho.nsa.gov
Mon Jan 7 15:41:32 UTC 2008
On Sat, 2008-01-05 at 11:17 -0500, Eric Paris wrote:
> On Sat, 2008-01-05 at 17:02 +0100, Christoph Höger wrote:
> > Am Samstag, den 05.01.2008, 10:22 -0500 schrieb Eric Paris:
> > > On Sat, 2008-01-05 at 14:58 +0100, Christoph Höger wrote:
> > > > Am Freitag, den 04.01.2008, 18:34 -0500 schrieb Eric Paris:
> > > > > On Fri, 2008-01-04 at 14:26 -0800, Clarkson, Mike R (US SSA) wrote:
> > > > > > Is there someplace I can go to find a description of the libselinux API?
> > > > >
> > > > > not sure, i just read the code :) the fedora libselinux-devel
> > > > > package provides man pages for most (maybe all?) of the interfaces.
> > > > >
> > > > > >
> > > > > > Is there a way to change the context of an existing process, without
> > > > > > having to execute a new process?
> > > > >
> > > > > yes, the permission is dyntransition in the process class. it is
> > > > > STRONGLY, let me say that again VERY STRONGLY, suggested that you don't
> > > > > make use of this facility. Basically you lose all seperation between
> > > > > those 2 domains. You don't have any assurance that the process before
> > > > > the transition didn't get hacked/corrupted/bugged and is now
> > > > > transitioning to a new domain but able to do the wrong things (or
> > > > > sometimes even worse not transition to the new domain at all)
> > > >
> > > > Hi, I don't think that it is that bad. Basically I think if you can
> > > > transition from dom_a to dom_b that still does not include transition
> > > > back to dom_a. So you can e.g. secure a new thread which handles a
> > > > client or something without using execve.
> > >
> > > dyntrans only works on single threaded processes.
> > >
> > > -Eric
> > > >
> > > > >
> > > > > I'm not sure what the rationale was to put it in originally but please
> > > > > just find a way to do it on an execve boundary.
> > > > >
> > > > > -Eric
> > > > >
> > > > > --
> > > > > fedora-selinux-list mailing list
> > > > > fedora-selinux-list at redhat.com
> > > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> > > >
> >
> > Hi,
> >
> > how does that work? After fork() a new thread/process should have the
> > same rights as its parent, so if dyntrans is allowed before fork(), it
> > should also work after that?
>
> /* Only allow single threaded processes to change context */
> if (atomic_read(&p->mm->mm_users) != 1) {
> struct task_struct *g, *t;
> struct mm_struct *mm = p->mm;
> read_lock(&tasklist_lock);
> do_each_thread(g, t)
> if (t->mm == mm && t != p) {
> read_unlock(&tasklist_lock);
> return -EPERM;
> }
> while_each_thread(g, t);
> read_unlock(&tasklist_lock);
> }
>
> You just explained the rationale why it should only work on single
> threaded processes :) Two threads share all of the same resources,
> if one of those is in dom_a and one of those is in dom_b you don't have
> any seperation between the domains. The thread in dom_b might
> (depending on the permissions of the code pages) be able to rewrite the
> code executing by the thread in dom_a. Now even without dom_b -> dom_a
> transition dom_b thread has full control in dom_a. Also remember that
> the thread in dom_b can write to data segments used by dom_a, so even if
> it can't rewrite its code pages it can probably pretty easily get it to
> call into a function it controls by rewriting its data pages (which
> obviously have no seperation)
>
> dyntransition is only allowed in single threaded processes. It can fork
> children after the transition, but if it forks before the transition it
> won't be allowed.
fork creates a child process, not another thread within the same
process.
The discussion above applies to clone() with CLONE_VM set, not to fork.
See the setcon(3) man page for a discussion of dynamic context
transitions.
An alternative to disallowing switching the security context of a
multi-threaded process altogether would be to provide a way to switch
the security context of all threads within a process atomically. I
think Ulrich wants something similar for uids and gids for POSIX
compliance in Linux, but it would require a shared credential structure
for all threads in a thread group, including the security label.
--
Stephen Smalley
National Security Agency
More information about the fedora-selinux-list
mailing list