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