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@xxxxxxxxxx > > > > 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. -Eric -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
