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(a)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