[sandbox] modifying the Xephyr window title (patch)
by Christoph A.
Hi,
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:
/usr/bin/firefox (sandbox_web_t)
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
break thinks.
regards,
Christoph A.
btw: secon's manpage doesn't contain the '-l' option.
11 years, 8 months
Policy for CouchDB
by Michael Milverton
Hi,
I'm in the process of writing a policy for couchdb (nosql database). I'm
using the selinux-polgengui and eclipse slide tools to help. I've hit a road
block because it won't start but I'm not getting any more AVC's. I'm
wondering if anybody might be able to offer some clue about getting more
AVC's from it because if it won't talk to me I can't get much further.
The only entries in audit.log are:
type=CRED_ACQ msg=audit(1309362790.614:1343): user pid=11935 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:initrc_t:s0
msg='op=PAM:setcred acct="couchdb" exe="/sbin/runuser" hostname=? addr=?
terminal=? res=success'
type=USER_START msg=audit(1309362790.619:1344): user pid=11935 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:initrc_t:s0
msg='op=PAM:session_open acct="couchdb" exe="/sbin/runuser" hostname=?
addr=? terminal=? res=success'
type=USER_END msg=audit(1309362790.640:1345): user pid=11935 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:initrc_t:s0
msg='op=PAM:session_close acct="couchdb" exe="/sbin/runuser" hostname=?
addr=? terminal=? res=success'
type=CRED_DISP msg=audit(1309362790.641:1346): user pid=11935 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:initrc_t:s0
msg='op=PAM:setcred acct="couchdb" exe="/sbin/runuser" hostname=? addr=?
terminal=? res=success'
type=SERVICE_START msg=audit(1309362790.676:1347): user pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=':
comm="couchdb" exe=2F62696E2F73797374656D64202864656C6574656429 hostname=?
addr=? terminal=? res=failed'
Now, it will start fine (and run) when it is unlabeled (not what I want of
course). Couchdb runs under the username/group couchdb but I haven't added
any transition rules for this yet (any help on this would be appreciated).
FC FILE:
/usr/bin/couchdb -- gen_context(system_u:object_r:couchdb_exec_t,s0)
/usr/bin/couchjs -- gen_context(system_u:object_r:couchdb_exec_t,s0)
TE FILE:
policy_module(couchdb,1.0.0)
require {
type bin_t;
type fs_t;
type proc_t;
}
type couchdb_t;
domain_type(couchdb_t)
permissive couchdb_t;
# Access to shared libraries
libs_use_ld_so(couchdb_t)
libs_use_shared_libs(couchdb_t)
miscfiles_read_localization(couchdb_t)
dev_read_urand(couchdb_t)
# Type for the daemon
type couchdb_exec_t;
files_type(couchdb_exec_t)
domain_entry_file(couchdb_t, couchdb_exec_t)
init_daemon_domain(couchdb_t, couchdb_exec_t)
# Logging
logging_send_syslog_msg(couchdb_t)
logging_log_file(couchdb_t)
# Temp files
type couchdb_tmp_t;
files_tmp_file(couchdb_tmp_t)
manage_dirs_pattern(couchdb_t, couchdb_tmp_t, couchdb_tmp_t)
manage_files_pattern(couchdb_t, couchdb_tmp_t, couchdb_tmp_t)
files_tmp_filetrans(couchdb_t, couchdb_tmp_t, { dir file })
#type couchdb_config_t;
files_read_etc_files(couchdb_t)
# /bin/basename and some others
allow couchdb_t bin_t:file { read getattr open execute execute_no_trans };
allow couchdb_t fs_t:filesystem getattr;
allow couchdb_t proc_t:file { read getattr open };
allow couchdb_t self:fifo_file { read write getattr };
# Not sure about this
auth_domtrans_chk_passwd(couchdb_t)
# Not sure about this either.
domain_use_interactive_fds(couchdb_t)
Any clues, tips, advice would be most appreciated
Thanks
12 years
updpwd AVC
by Tony Molloy
Hi,
On a fully updated CentOS 5.7 box I get the following AVC
Summary:
SELinux is preventing unix_update (updpwd_t) "getattr" to / (fs_t).
Detailed Description:
SELinux denied access requested by unix_update. It is not expected
that this
access is required by unix_update and this access may signal an
intrusion
attempt. It is also possible that the specific version or
configuration of the
application is causing it to require additional access.
Allowing Access:
You can generate a local policy module to allow this access - see FAQ
(http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can
disable
SELinux protection altogether. Disabling SELinux protection is not
recommended.
Please file a bug report
(http://bugzilla.redhat.com/bugzilla/enter_bug.cgi)
against this package.
Additional Information:
Source Context system_u:system_r:updpwd_t
Target Context system_u:object_r:fs_t
Target Objects / [ filesystem ]
Source unix_update
Source Path <Unknown>
Port <Unknown>
Host a.b.c.d
Source RPM Packages
Target RPM Packages filesystem-2.4.0-3.el5.centos
Policy RPM selinux-policy-2.4.6-316.el5
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name catchall
Host Name a.b.c.d
Platform Linuxl a.b.c.d 2.6.18-274.3.1.el5
#1 SMP Tue Sep 6 20:13:52 EDT 2011
x86_64 x86_64
Alert Count 11
First Seen Fri Feb 25 15:39:33 2011
Last Seen Mon Sep 26 14:18:54 2011
Local ID 275eef01-114a-419b-9df0-4bb81932bc5e
Line Numbers
Raw Audit Messages
host=a.b.c.d type=AVC msg=audit(1317043134.620:3620): avc: denied {
getattr } for pid=21354 comm="unix_update" name="/" dev=sda5 ino=2
scontext=system_u:system_r:updpwd_t:s0
tcontext=system_u:object_r:fs_t:s0 tclass=filesystem
I can generate a local policy module.
Thanks,
Tony
12 years, 5 months
fixfiles onboot question
by Russell Golden
Does "fixfiles -F onboot" use the -F option at all, or does it just
run the normal fixfiles routine? The man page lists "fixfiles onboot"
as the only usage for the onboot parameter, but I'd like to see the
security contexts fixed for things in /var/www/cherokee. I don't know
if that even matters or not.
Thank you.
--
Russell Golden
niveusluna(a)niveusluna.org
(972) 836-7128
--
"We are the Borg. Lower your shields and surrender your ships. We will
add your biological and technological distinctiveness to our own. Your
culture will adapt to service us. Resistance is futile."
12 years, 5 months
"semanage dontaudit off" or "semodule -DB"
by Göran Uddeborg
When trying analyze things that don't work as expected, I sometimes
need to disable the dontaudit rules from the policy. There seems to
be (at least) two ways to do that:
semanage dontaudit off
and
semodule -DB
Is there some difference in the effect of these two commands? Or is
it just two ways to do the same thing?
12 years, 5 months
httpd_sys_content_rw_t
by Vadym Chepkov
Hi,
I think man httpd_selinux is outdated in RHEL6
it looks like proper name for httpd_sys_content_rw_t is httpd_sys_rw_content_t.
at least rectorecon is trying to correct it all the time :
for example:
restorecon reset /var/www/sel_blog/wp-content/uploads/2011/01/logo-150x150.jpg context system_u:object_r:httpd_sys_rw_content_t:s0->system_u:object_r:httpd_sys_content_rw_t:s0
Vadym
12 years, 5 months
php error log policy
by Vadym Chepkov
Hi,
php module has a capability to write errors to a log file.
Since unlike other apache logs this one is updated by a child I had to create a separate directory where apache user would have write access:
error_log = /var/log/php/php_error.log
in RHEL6 I can find an existing context suitable for this though.
I can't use httpd_log_t, because php log is opened for "writing", not "appending" and if I use any other httpd "working" contexts, logrotate is not allowed to rotate this log.
Shall I open a bugzilla request or there is something I overlooked?
Thanks,
Vadym
12 years, 5 months
List of avc for fedora 16
by David Highley
I checked bugzilla but did not see anything about this list of avc
alerts for fedora 16. Should they be reported or is something miss
configured?
#============= accountsd_t ==============
#!!!! This avc is allowed in the current policy
allow accountsd_t hi_reserved_port_t:tcp_socket name_bind;
#!!!! This avc is allowed in the current policy
allow accountsd_t portmap_port_t:tcp_socket name_connect;
#!!!! This avc is allowed in the current policy
allow accountsd_t var_yp_t:dir search;
#============= automount_t ==============
#!!!! This avc is allowed in the current policy
allow automount_t var_yp_t:file read;
#============= policykit_t ==============
#!!!! This avc is allowed in the current policy
allow policykit_t hi_reserved_port_t:tcp_socket name_bind;
#!!!! This avc is allowed in the current policy
allow policykit_t kerberos_port_t:tcp_socket name_bind;
#!!!! This avc is allowed in the current policy
allow policykit_t kprop_port_t:tcp_socket name_bind;
#!!!! This avc is allowed in the current policy
allow policykit_t portmap_port_t:tcp_socket name_connect;
#!!!! This avc is allowed in the current policy
allow policykit_t var_yp_t:dir search;
#============= sshd_t ==============
#!!!! This avc is allowed in the current policy
allow sshd_t ftp_port_t:tcp_socket name_bind;
#!!!! This avc is allowed in the current policy
allow sshd_t hi_reserved_port_t:tcp_socket name_bind;
#!!!! This avc is allowed in the current policy
allow sshd_t hi_reserved_port_t:udp_socket name_bind;
#!!!! This avc is allowed in the current policy
allow sshd_t spamd_port_t:tcp_socket name_bind;
#!!!! This avc is allowed in the current policy
allow sshd_t var_yp_t:dir search;
#============= system_dbusd_t ==============
#!!!! This avc is allowed in the current policy
allow system_dbusd_t hi_reserved_port_t:tcp_socket name_bind;
#!!!! This avc is allowed in the current policy
allow system_dbusd_t portmap_port_t:tcp_socket name_connect;
#!!!! This avc is allowed in the current policy
allow system_dbusd_t rndc_port_t:tcp_socket name_bind;
#============= xdm_dbusd_t ==============
#!!!! This avc is allowed in the current policy
allow xdm_dbusd_t hi_reserved_port_t:tcp_socket name_bind;
#!!!! This avc is allowed in the current policy
allow xdm_dbusd_t portmap_port_t:tcp_socket name_connect;
12 years, 5 months
Re: selinux Digest, Vol 91, Issue 15
by Antonio Trande
With my Fedora 15 64bit this problem doesn't never appear; with other Fedora
system seems present.
$ ls -Z /opt/google/chrome/chrome
> -rwxr-xr-x. root root system_u:object_r:execmem_exec_t:s0
> /opt/google/chrome/chrome
> $ ls -Z /opt/google/chrome/chrome-sandbox
> -rwsr-xr-x. root root system_u:object_r:chrome_sandbox_exec_t:s0
> /opt/google/chrome/chrome-sandbox
> $ getsebool -a | grep chrome
> $ getsebool -a | grep exe
> allow_execheap --> off
> allow_execmem --> on
> allow_execmod --> off
> allow_execstack --> off
> allow_guest_exec_content --> off
> allow_java_execstack --> off
> allow_mplayer_execstack --> off
> allow_nsplugin_execmem --> on
> allow_staff_exec_content --> on
> allow_sysadm_exec_content --> on
> allow_user_exec_content --> on
> allow_xguest_exec_content --> on
> allow_xserver_execmem --> off
> dhcpc_exec_iptables --> off
> httpd_execmem --> off
> httpd_ssi_exec --> off
> httpd_tmp_exec --> off
> xdm_exec_bootloader --> off
>
If i change execmem boolean to off, selinux reports an AVC message (in
attachment).
I do not understand ...
2011/9/25 <selinux-request(a)lists.fedoraproject.org>
> Send selinux mailing list submissions to
> selinux(a)lists.fedoraproject.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://admin.fedoraproject.org/mailman/listinfo/selinux
> or, via email, send a message with subject or body 'help' to
> selinux-request(a)lists.fedoraproject.org
>
> You can reach the person managing the list at
> selinux-owner(a)lists.fedoraproject.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of selinux digest..."
>
>
> Today's Topics:
>
> 1. execmod access to '/opt/google/chrome/chrome' file
> (Antonio Trande)
> 2. Re: execmod access to '/opt/google/chrome/chrome' file
> (Dominick Grift)
> 3. Re: execmod access to '/opt/google/chrome/chrome' file
> (Trevor Hemsley)
> 4. httpd_sys_content_rw_t (Vadym Chepkov)
> 5. Re: httpd_sys_content_rw_t (Vadym Chepkov)
> 6. Re: List of avc for fedora 16 (David Highley)
> 7. Re: List of avc for fedora 16 (Dominick Grift)
> 8. Re: httpd_sys_content_rw_t (Dominick Grift)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 24 Sep 2011 16:06:31 +0200
> From: Antonio Trande <anto.trande(a)gmail.com>
> Subject: execmod access to '/opt/google/chrome/chrome' file
> To: selinux(a)lists.fedoraproject.org
> Message-ID:
> <CAATtwDXHkAbZAGgLkU7j7OY7HeLvx+5EnrniTEfOF2Q=eJ5qwA(a)mail.gmail.com
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> This problem is appeared with chrome executable:
>
> SELinux is preventing /opt/google/chrome/chrome from execmod access on the
> file
> /opt/google/chrome/chrome.
>
> setroubleshoot suggests to change the label on
> '/opt/google/chrome/chrome' how textrel_shlib_t type or to allow
> chrome to have execmod access on the chrome file.
> But does not happen always (never to me).
>
> Could you give more infos about this behavior ?
>
> Thanks.
>
>
>
> --
> *Antonio Trande
> "Fedora Ambassador"
>
> **mail*: mailto:sagitter@fedoraproject.org <sagitter(a)fedoraproject.org>
> *Homepage*: http://www.fedora-os.org
> *Sip Address* : sip:sagitter AT ekiga.net
> *Jabber <http://jabber.org/>* :sagitter AT jabber.org
> *GPG Key: CFE3479C*
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.fedoraproject.org/pipermail/selinux/attachments/20110924/de7...
>
> ------------------------------
>
> Message: 2
> Date: Sat, 24 Sep 2011 16:23:29 +0200
> From: Dominick Grift <dominick.grift(a)gmail.com>
> Subject: Re: execmod access to '/opt/google/chrome/chrome' file
> To: selinux(a)lists.fedoraproject.org
> Message-ID: <1316874209.9488.13.camel(a)x220.mydomain.internal>
> Content-Type: text/plain; charset="utf-8"
>
> On Sat, 2011-09-24 at 16:06 +0200, Antonio Trande wrote:
> > This problem is appeared with chrome executable:
> >
> > SELinux is preventing /opt/google/chrome/chrome from execmod access on
> the file
> > /opt/google/chrome/chrome.
> >
> > setroubleshoot suggests to change the label on
> '/opt/google/chrome/chrome' how textrel_shlib_t type or to allow chrome to
> have execmod access on the chrome file.
> > But does not happen always (never to me).
> >
> >
> > Could you give more infos about this behavior ?
>
> I can tell you that this is bad behaviour by chrome. I can tell you that
> this issue is known but that this issue is obviously not fixed yet.
>
> SElinux protects the system from chrome currently. SElinux is blocking
> chrome trying to do bad things.
>
> One could argue that SElinux should not try and protect users by default
> (unconfined users) butthat is currently not the case.
>
> there is , i believe, a way to stop selinux trying to protect you from
> chromes evil ways.
>
> youu can try and "chcon -t bin_t /opt/google/chrome/chrome-sandbox" or
> "chcon -t bin_t /usr/lib/chromium-browser/chrome-sandbox" respectively
> depending on where it is located.
>
> Additionally one may be required to toggle the allow_execmem and
> allow_execmod booleans to true.
>
> Doing this will leave your system wide open to browser and browser
> plugin attacks.
>
> To undo this simply
> restorecon /opt/google/chrome/chrome-sandbox
> /usr/lib/chromium-browser/chrome-sandbox
> and toggle the allow_execmem and allow_execmod booleans to their
> previous state.
>
> You can also use the mozilla browser, unlike chrome this browser does
> not try to hijack your system (at least not yet)
>
> > Thanks.
> >
> >
> > --
> > Antonio Trande
> > "Fedora Ambassador"
> >
> > mail: mailto:sagitter@fedoraproject.org
> > Homepage: http://www.fedora-os.org
> > Sip Address : sip:sagitter AT ekiga.net
> > Jabber :sagitter AT jabber.org
> > GPG Key: CFE3479C
> >
> > --
> > selinux mailing list
> > selinux(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/selinux
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 836 bytes
> Desc: This is a digitally signed message part
> Url :
> http://lists.fedoraproject.org/pipermail/selinux/attachments/20110924/5fe...
>
> ------------------------------
>
> Message: 3
> Date: Sat, 24 Sep 2011 15:32:36 +0100
> From: Trevor Hemsley <trevor.hemsley(a)ntlworld.com>
> Subject: Re: execmod access to '/opt/google/chrome/chrome' file
> Cc: selinux(a)lists.fedoraproject.org
> Message-ID: <4E7DEA04.3050806(a)ntlworld.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Dominick Grift wrote:
> > On Sat, 2011-09-24 at 16:06 +0200, Antonio Trande wrote:
> >
> >> This problem is appeared with chrome executable:
> >>
> >> SELinux is preventing /opt/google/chrome/chrome from execmod access on
> the file
> >> /opt/google/chrome/chrome.
> >>
> >> setroubleshoot suggests to change the label on
> '/opt/google/chrome/chrome' how textrel_shlib_t type or to allow chrome to
> have execmod access on the chrome file.
> >> But does not happen always (never to me).
> >>
> >>
> >> Could you give more infos about this behavior ?
> >>
> >
> > I can tell you that this is bad behaviour by chrome. I can tell you that
> > this issue is known but that this issue is obviously not fixed yet.
> >
> http://code.google.com/p/chromium/issues/detail?id=87704 is the bug
> report about it for Chrome.
>
12 years, 5 months