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