If most of your windows are sandboxed applications, your bar looks like:
[Sandbox sandbo..] [Sandbox sandbo..] [Sandbox sandbo..]
and it is hard to find a specific application.
example of a current Xephyr title:
Sandbox sandbox_web_t:s0:c112,c991 -- /usr/bin/firefox
with the modification in the attached patch titles will look like:
and it should be easier to find a specific application.
In addition to the type I would find it handy to also include the
DISPLAY in the title (needed when using xsel for copy'n paste).
The second patch only adds '-nolisten tcp' to Xephyr, but if there are
use cases where one needs Xephyr to open a listener this patch will
btw: secon's manpage doesn't contain the '-l' option.
Three times over the last few days, the Software Update program has
announced that it has 10 updates it wants to install. I okay this,
provide the password to approve it, the program gets the list of pkgs.
(a few SELinux libraries, a microcode reader, an ffmpeg lib, among
others) downloads, attempts to install, fails and closes; the details
This is Fedora 17 64-bit Gnome on a Toshiba Satellite A665.
Thought you might like to know of this.
I'm having trouble to active SELinux on our RHEL 6 Linux system.
We have some sort of special installation framework (cobbler and puppet)
and initially disabled SELinux (which is fine)
[output from Kickstart]
%packages --excludedocs --nobase
But for some high Security Risk systems, it's required to turn it on
So I followed the guidance on:
ling_and_Disabling_SELinux.html to enable SELinux again on these systems
Unfortunately does the system not initiate SELinux correctly nor do I
see any hint where the problem is:
tgl90a-8401 root:/etc/init $ sestatus
SELinux status: disabled
tgl90a-8401 root:/etc/init $ cat /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
# SELINUXTYPE= can take one of these two values:
# targeted - Targeted processes are protected,
# mls - Multi Level Security protection.
The only thing I can see is:
tgl90a-8401 root:/etc/init $ cat /var/log/messages
Jun 13 13:41:30 tgl90a-8401 kernel: SELinux: Initializing.
Does anybody know if I need additional packages on the system or any
special setting set?
If tried "permissive" mode with /.autorelable - which didn't
I also installed @Base Group to ensure nothing is missing - but
still the same result
I've tried it with the same setup on RHEL 5 which perfectly worked - but
not on RHEL 6!
So I'm really looking forward to get some hints/tips
Thanks and all the best,
I'm updating a custom policy from CentOS 5 to CentOS 6. The module builds
successfully, but fails to load:
# semodule -i mypolicy.pp
/etc/selinux/targeted/contexts/files/file_contexts: Invalid argument
libsemanage.semanage_install_active: setfiles returned error code 1.
It took me some time to work out that the error should have read:
File context already exists for /var/run/passenger: mypolicy.fc line 5
Now that I know there is already policy for Passenger, I can adjust mine
accordingly. Any chance of getting a more helpful version of the error
included in semodule?
"To err is human; to purr, feline."
when i execute #restorecon -R / , all the output is "... operation not
support". I had check the source code, and in
sbsec = inode->i_sb->s_security;
if (!(sbsec->flags & SE_SBLABELSUPP))
it returned. The SE_SBLABELSUPP defined as 0x40, i want to know how can i
do to make the filesystem to support the SecurityContext of selinux.
Howdy All -
I just installed F17 i386 on my daughter's laptop and ran yum update. I
Updating : selinux-policy-3.10.0-125.fc17.noarch
/usr/share/selinux/devel/include/services/jetty.if: Syntax error on line
180472 jetty_cache_t [type=IDENTIFIER]
It seems non-fatal, but I am not sure. Shall I BZ it, or do you already
know about it?