Under policy-sources-1.11.2-18:
audit(1083131647.146:0): avc: denied { signal } for pid=28661 exe=/usr/bin/gdb scontext=aleksey:staff_r:staff_mozilla_t tcontext=aleksey:staff_r:staff_t tclass=process
On Wed, 2004-04-28 at 02:05, Aleksey Nogin wrote:
Under policy-sources-1.11.2-18:
audit(1083131647.146:0): avc: denied { signal } for pid=28661 exe=/usr/bin/gdb scontext=aleksey:staff_r:staff_mozilla_t tcontext=aleksey:staff_r:staff_t tclass=process
In general, you'd like to confine mozilla so that if it is subverted by malicious code, then it can't do much harm. So allowing it to send signals back to the user domain isn't desirable. For development environments, you might want a policy tunable or boolean to allow such permissions, but not for operational use.
On 28.04.2004 05:11, Stephen Smalley wrote:
On Wed, 2004-04-28 at 02:05, Aleksey Nogin wrote:
Under policy-sources-1.11.2-18:
audit(1083131647.146:0): avc: denied { signal } for pid=28661 exe=/usr/bin/gdb scontext=aleksey:staff_r:staff_mozilla_t tcontext=aleksey:staff_r:staff_t tclass=process
In general, you'd like to confine mozilla so that if it is subverted by malicious code, then it can't do much harm. So allowing it to send signals back to the user domain isn't desirable. For development environments, you might want a policy tunable or boolean to allow such permissions, but not for operational use.
Note that exe is gdb, not mozilla. How did gdb end up in mozilla_t?
On Wed, 2004-04-28 at 16:29, Aleksey Nogin wrote:
Note that exe is gdb, not mozilla. How did gdb end up in mozilla_t?
The pid and exe information doesn't necessarily correlate with the source context; it is just derived from the "current" process. For example, if gdb waits on mozilla, there is a mozilla-to-gdb signal check (typically sigchld when SIGCHLD is the exit signal but other signals are possible).
selinux@lists.fedoraproject.org