[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, 3 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
11 years, 6 months
SEL & Spamassassin
by Arthur Dent
Hello All,
I have just upgraded (clean install) from F13 to F15 and installed
spamassassin via yum.
At the same time I also installed the plugins Pyzor, Razor and iXhash.
In Permissive mode something in those triggers a strange AVC:
SELinux is preventing /bin/systemd-tty-ask-password-agent from read access on the fifo_file 136:0.
Here is the detail:
Raw Audit Messages
type=AVC msg=audit(1307797576.537:29628): avc: denied { read } for pid=10471 comm="systemd-tty-ask" name="136:0" dev=tmpfs ino=282609 scontext=unconfined_u:system_r:systemd_passwd_agent_t:s0 tcontext=unconfined_u:object_r:init_var_run_t:s0 tclass=fifo_file
type=AVC msg=audit(1307797576.537:29628): avc: denied { open } for pid=10471 comm="systemd-tty-ask" name="136:0" dev=tmpfs ino=282609 scontext=unconfined_u:system_r:systemd_passwd_agent_t:s0 tcontext=unconfined_u:object_r:init_var_run_t:s0 tclass=fifo_file
type=SYSCALL msg=audit(1307797576.537:29628): arch=i386 syscall=open success=yes exit=ESRCH a0=8ca9080 a1=88900 a2=0 a3=bf8fba54 items=0 ppid=10470 pid=10471 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm=systemd-tty-ask exe=/bin/systemd-tty-ask-password-agent subj=unconfined_u:system_r:systemd_passwd_agent_t:s0 key=(null)
Hash: systemd-tty-ask,systemd_passwd_agent_t,init_var_run_t,fifo_file,read
audit2allow
#============= systemd_passwd_agent_t ==============
allow systemd_passwd_agent_t init_var_run_t:fifo_file { read open };
audit2allow -R
#============= systemd_passwd_agent_t ==============
allow systemd_passwd_agent_t init_var_run_t:fifo_file { read open };
The other slightly odd thing is that when I place the system back into
Enforcing mode I get no AVCs, but some of the Spamassassin checks
(Especially iXhash I think) don't seem to be run, but give no errors.
Anyway, the above AVC looked strange and I didn't want to create a local
policy module for it until I had checked with the chaps here...
Thanks in advance for any advice or suggestions...
Mark
12 years
SSSD Local Auth and SELinux support
by Matthew Ife
First a breif explanation of what SSSD is doing in case people are
unfamiliar/
SSSD is a security services daemon. Its main purpose is to provide a
single abstraction layer for handling various name and authentication
services which previously would be done through individual configuration
entries (such as krb5.conf or ldap.conf).
One of the most promising features is the use of a local authentication
provider. This is somewhat a reinvention of shadow/passwd/group files in
a single database managed through sssd but has a significant advantage;
authentication and password alteration is done by-proxy of the sssd
daemon meaning applications do not require read/write access to the sssd
database files. You can still of course use traditional auth methods
using PAM.
Implementation is done using a series of user and group userland
equivalents to the stuff found in shadow-utils (sss_useradd,
sss_groupmod etc) which make direct changes to the databse files that
sssd uses at the back.
An interesting aspect I can see to SSSD Local services is that I can now
cheaply and logically segregate system users from non-system users,
which I would prefer to do. This in turn allows the system to manage
system related users in passwd and non-system related ones can be left
to the sysadmin to do using the sss_* management utilities. This should
hopefully make the shadow file almost redundant, offering only password
storage for root and not exposing every other user on the system.
Another big advantage from an implementation end is sss databases
require far less access throughout the system, rather all requests are
via a single source (sssd) which other services hook into by-proxy using
PAM. This reduces the scope of access a typical operating system needs
to give to be able to manage non-system users. From a quick check I did
database entries from SSSD would require read access from only 12
domains whereas shadow requires 29 subjects.
Firstly, SELinux offers very little support for sss local databases
treating them like standard sssd_var_lib folders, this provides 33
domains (some of which are clearly unnecessary like mplayer and
rgmanager) read access to these files. Fair enough - so I go about
adding an extra restricted type of sssd called sssd_db_t which would
manage the database files for sss services.
I mark the sssd_db type as a security_file_type, when I then compare it
to what shadow shows (which is also a security file) there are less
domains that can read this file than can for sssd_db types. Whats the
crack?
Well - the issue here is that in main policy - there exists a macro
auth_read_all_(files|dirs)_except_shadow which implements an all files
type without shadow being permitted.
Herein lies my problem. Firstly, SSS is an optional module. Monolithic
should be as lean as possible. But nature of this macro is it does:
allow domain { files_type -shadow_t }:file read_file_perms
Currently in refpolicy its impossible to have another file type put in
there thats from an optional module!
This problem means I can never get sss restricted down to the same as
shadow (without marking the file as shadow which gives sssd access to
the shadow file which I DONT want to do!). In fact I could give it even
less scope than that but its not possible in refpolicy.
One way around this however, is to change the macros in refpolicy so it
becomes something more like:
interface(`auth_read_all_files_except_auth_file',`
gen_require(`
attribute authentication_file;
')
files_read_all_files_except($1, $2 -authentication_file)
')
In refpolicy we declare attribute shadow_t as a authentication_file.
Then for future policy writers who consider their file shadow-like in
security they can go:
typeattribute my_secure_t authentication_file;
(or of course provide a wrapper module that performs the same task)
To get the same effect as a shadow file at very little effort.
This is a somewhat core change to policy as shadow_t will be one of
these types that have had a lot of thought put into their access
control. I want to know if people think I am thinking too far ahead here
or not.
Personally - I see a lot of promise with sss and local. It means I can
prevent rpm/dpkg from messing with my legit users on a system by doing
something daft. And services like sasl, smbd or passwd wont need access
to it directly either reducing access scope for my users. Plus my shadow
file ends up containing no passwords in it! (lock root, use sudo)
Albeit, I wont want to use it going forward myself until I can get some
assurance its at least as secure from the O/S level as shadow is.
Something which at the moment is impossible.
Thoughts, insights and alternatives to my problem are much appreciated!
12 years, 2 months
google-chrome
by Genes MailLists
I notice when I start up google-chrome (F15) I get this:
SELinux is preventing /opt/google/chrome/chrome from execmod access on
the file /opt/google/chrome/chrome.
***** Plugin allow_execmod (91.4 confidence) suggests
**********************
If you want to allow chrome to have execmod access on the chrome file
Then you need to change the label on '/opt/google/chrome/chrome'
Do
# semanage fcontext -a -t textrel_shlib_t '/opt/google/chrome/chrome'
# restorecon -v '/opt/google/chrome/chrome'
***** Plugin catchall (9.59 confidence) suggests
***************************
Is the above suggestion a reasonable fix ?
thanks as always !!
gene/
12 years, 2 months
a context question
by mark
I have a system that's creates a lot of temp files via http & perl CGI
scripts. What is the correct context for the temp files?
mark
12 years, 2 months
Resizing firefox sandbox window
by GSO
A quick note on resizing the sandbox window that firefox runs in.
I assum that the sandbox sets some window hints (or something) that prevents
the sandbox window from resizing. I don't know what the reason is behind
this, but I have been using TWM, which I assume is too old to take any
notice of whatever the more recent (openbox, metacity) wms pick up on and
use as a cue to lock the window size. TWM will quite happily resize the
sandbox window, and what's more firefox quite happily resizes in the window
(mentioning which is the purpose of this post).
Is there any real need to lock the size of a sandbox window? (Rhetorical
question, for anyone who may care to take a second look at the issue.)
12 years, 3 months
strange semodule_expand error during linking
by Mr Dash Four
I am trying to build a cut-down version of the targeted policy where I
have turned quite a few modules in modules-targeted.conf to "off"
instead of "module" (i.e. no compilation and inclusion in the final
version of the policy). Compilation and linking goes well, though during
the final stage I am getting the following error:
/usr/bin/semodule_expand tmp/test.lnk tmp/policy.bin
libsepol.sepol_module_package_read: invalid module in module package (at
section 0)
/usr/bin/semodule_expand: Error in reading package from tmp/test.lnk
make: *** [validate] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.3z0Tfc (%install)
I am using the latest policy for FC15. Any ideas what could be the cause
for this?
12 years, 3 months
Fwd: Is it possible to run chromium in a SELinux sandbox?
by GSO
On 23 June 2011 13:22, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 06/23/2011 06:29 AM, GSO wrote:
> > This thread went offline, however to bring things back online, it
> > appears at least the binary download (running on SL6) of Firefox 5 just
> > released does not work in the sandbox either. The SELinux audit
> > messages are:
> >
> > Jun 22 21:40:22 localhost kernel: SELinux: Permission audit_access in
> > class dir not defined in policy.
> > Jun 22 21:40:22 localhost kernel: SELinux: Permission execmod in class
> > dir not defined in policy.
> > Jun 22 21:40:22 localhost kernel: SELinux: Permission audit_access in
> > class lnk_file not defined in policy.
> > Jun 22 21:40:22 localhost kernel: SELinux: Permission open in class
> > lnk_file not defined in policy.
> > Jun 22 21:40:22 localhost kernel: SELinux: Permission execmod in class
> > lnk_file not defined in policy.
> > Jun 22 21:40:22 localhost kernel: SELinux: Permission audit_access in
> > class chr_file not defined in policy.
> > Jun 22 21:40:22 localhost kernel: SELinux: Permission audit_access in
> > class blk_file not defined in policy.
> > Jun 22 21:40:22 localhost kernel: SELinux: Permission execmod in class
> > blk_file not defined in policy.
> > Jun 22 21:40:22 localhost kernel: SELinux: Permission audit_access in
> > class sock_file not defined in policy.
> > Jun 22 21:40:22 localhost kernel: SELinux: Permission execmod in class
> > sock_file not defined in policy.
> > Jun 22 21:40:22 localhost kernel: SELinux: Permission audit_access in
> > class fifo_file not defined in policy.
> > Jun 22 21:40:22 localhost kernel: SELinux: Permission execmod in class
> > fifo_file not defined in policy.
> > Jun 22 21:40:22 localhost kernel: SELinux: Permission syslog in class
> > capability2 not defined in policy.
> > Jun 22 21:40:22 localhost kernel: SELinux: the above unknown classes and
> > permissions will be allowed
> > Jun 22 21:40:24 localhost dbus: avc: received policyload notice
> (seqno=5)
> > Jun 22 21:40:24 localhost dbus: avc: received policyload notice
> (seqno=5)
> > Jun 22 21:40:24 localhost dbus: avc: received policyload notice
> (seqno=5)
> > Jun 22 21:40:24 localhost dbus: avc: received policyload notice
> (seqno=5)
> > Jun 22 21:40:24 localhost dbus: avc: received policyload notice
> (seqno=5)
> > Jun 22 21:40:24 localhost dbus: [system] Reloaded configuration
> >
> > The sandbox window starts up but crashes before any sign of FF
> > materialises, works fine in permissive mode or unsandboxed otherwise.
> > I've put the FF binaries in /opt.
> >
> > On 19 June 2011 17:53, Dominick Grift <domg472(a)gmail.com
> > <mailto:domg472@gmail.com>> wrote:
> >
> >
> >
> > On Sun, 2011-06-19 at 13:57 +0100, GSO wrote:
> > > The default build using the google repos results in chromium
> > grinding to a
> > > halt with a black window when run in a sandbox. Is it technically
> > possible
> > > to run chrome in a sandbox, would building from source fix this at
> > all?
> >
> > I do not think it will work since both sandbox an chrome use
> namespace
> > and chrome cant run if sandbox already runs in a namespace (or
> something
> > along those lines is my understanding if this issue)
> >
> > > --
> > > selinux mailing list
> > > selinux(a)lists.fedoraproject.org
> > <mailto:selinux@lists.fedoraproject.org>
> > > https://admin.fedoraproject.org/mailman/listinfo/selinux
> >
> >
> >
> >
> > --
> > selinux mailing list
> > selinux(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/selinux
>
> I looked for firefox5 x86_64 and did not quickly find it, if you know
> where there is a link, I will look into what is going on, otherwise I
> will wait until Fedora Packages it. It does seem strange that you are
> getting those
>
> Permission audit_access in class sock_file not defined in policy.
>
> errors, What OS are you using? What kernel?
>
>
That was Scientific Linux 6, I was also running Tor (through openvpn), so
that might have complicated matters. I had also been messing around with
Tor to get it to send all net traffic through tor, and the install was
tainted at that point (I never was able to get that to work, similar SELInux
audit errors to the above funnily enough). I had also built and installed
the latest kernel as I have to do to get my webcams working (2 cams I have
do not work with the default RHEL6 kernel).
However I've just installed the Fedora security spin, should be an untainted
install (I am 'under attack' here!), Firefox 5 likewise crashes, though with
no SELinux audit messages in /var/log/messages as far as I can see (just a
few 'received policyload notice' lines).
Likewise chromium grinds to a halt at the usual black background, no SELinux
audit messages again, not even the 'policyload' notice ones (assuming I've
got it set up properly to report them).
12 years, 3 months
Is it possible to run chromium in a SELinux sandbox?
by GSO
The default build using the google repos results in chromium grinding to a
halt with a black window when run in a sandbox. Is it technically possible
to run chrome in a sandbox, would building from source fix this at all?
12 years, 3 months
