sandbox cleanup?
by Christoph A.
Hi,
I just noticed that I have over 100 processes running in the
sandbox_web_client_t domain, although I closed all my sandbox windows.
ps auxZ|grep sandbox_web_client_t|grep -c /usr/libexec/gvfsd
52
ps auxZ|grep sandbox_web_client_t|grep -c '/bin/dbus-daemon --fork
--print-pid 5 --print-address 7 --session'
51
Shouldn't they be killed after I closed all sandbox windows?
Kind regards,
Christoph
12 years, 5 months
sandbox: open new firefox tab from outside
by Christoph A.
Hi,
I was using firefox within sandboxes for a while without perm. home
directory.
To store bookmarks, addons and so on, I started to use perm. homedir (-H).
Because firefox does not allow multiple concurrent sessions (lock on
.mozilla) it is not possible to open multiple websites when specifying
the same sandbox homedir, hence I'm looking for a possibility to open
new websites within a running sandbox from outside.
Without sandboxes everyone can open new websites in a running firefox
instance using:
firefox -remote "openurl(http://www.mozilla.org)"
sandbox scenario:
1. step:
start firefox:
sandbox -X -H homedir -T tempdir -t sandbox_web_t -l s0:c100,c100 firefox
2. step:
sandbox -H homedir -T tempdir -t sandbox_web_t -l s0:c100,c100 firefox
-remote "openurl(http://www.mozilla.org)"
My current attempts fail because I'm unable use the '-l' option
(#632377) but would the policy allow the 'firefox -remote' command if
type and security level matches with the already running sandbox?
kind regards,
Christoph
12 years, 7 months
recently-used.xbel wrong context
by Trevor Hemsley
Hi
I'm running Centos 5.5 with all the most recent patches applied and am
seeing a strange problem with a file in my home directory called
.recently-used.xbel. It keeps getting the wrong selinux context assigned
to it though I have no idea what is changing it or when.
[trevor@trevor4 ]$ ls -aZl ~/.recently-used.xbel
-rw-rw-r-- 1 user_u:object_r:user_home_dir_t trevor trevor 148481 Feb
18 20:22 /home/trevor/.recently-used.xbel
[trevor@trevor4 ]$ chcon --reference=/home/trevor/.recently-used
~/.recently-used.xbel
[trevor@trevor4 ]$ ls -aZl ~/.recently-used.xbel
-rw-rw-r-- 1 user_u:object_r:user_home_t trevor trevor 148481 Feb
18 20:22 /home/trevor/.recently-used.xbel
It's a file not a directory yet it is being labelled as home_dir_t not
home_t and this causes avc messages. I change it back using the chcon
command above and it stays that way for a while and a few
days/hour/weeks later, it comes back as home_dir_t again. I'm not sure
what it is that triggers the re-mislabelling but I do know that I
'fixed' this via chcon about a week ago and now it's back again and it's
not the first time that this has happened. Looking at these two avcs it
would appear that I 'fixed' it shortly after the 13th and it came back
sometime today or yesterday at a guess.
63. 13/02/11 02:12:53 smbd user_u:system_r:smbd_t:s0 4 file getattr
user_u:object_r:user_home_dir_t:s0 denied 47358
64. 19/02/11 17:39:10 smbd user_u:system_r:smbd_t:s0 4 file getattr
user_u:object_r:user_home_dir_t:s0 denied 54205
[root@trevor4 ~]# ausearch -i -a 54205
----
type=SYSCALL msg=audit(19/02/11 17:39:10.711:54205) : arch=x86_64
syscall=stat success=yes exit=0 a0=7fffe6a808d0 a1=7fffe6a80000
a2=7fffe6a80000 a3=7fffe6a804d0 items=0 ppid=2533 pid=15831 auid=trevor
uid=trevor gid=root euid=trevor suid=root fsuid=trevor egid=trevor
sgid=root fsgid=trevor tty=(none) ses=2 comm=smbd exe=/usr/sbin/smbd
subj=user_u:system_r:smbd_t:s0 key=(null)
type=AVC msg=audit(19/02/11 17:39:10.711:54205) : avc: denied {
getattr } for pid=15831 comm=smbd path=/home/trevor/.recently-used.xbel
dev=dm-5 ino=10453859 scontext=user_u:system_r:smbd_t:s0
tcontext=user_u:object_r:user_home_dir_t:s0 tclass=file
I haven't run a relabel of my system recently and even if I had it
hasn't been since the machine was last rebooted..
[root@trevor4 ~]# uptime
18:10:11 up 52 days, 7:58, 15 users, load average: 0.43, 0.43, 0.25
[root@trevor4 ~]#
[trevor@trevor4 ~]$ rpm -q selinux-policy
selinux-policy-2.4.6-279.el5_5.2
Anyone got any ideas what could be causing this? I can't see anything in
semanage fcontext that could be doing it...
[root@trevor4 ~]# semanage fcontext -l | grep home
/usr/sbin/genhomedircon regular file
system_u:object_r:semanage_exec_t:s0
/usr/lib/oddjob/mkhomedir regular file
system_u:object_r:oddjob_mkhomedir_exec_t:s0
Yours
Baffled of Brighton :)
12 years, 9 months
Using dyntransition to reduce privileges for Web application
by Scott Gifford
Hello,
I'm experimenting with SELinux policies again. I've got a test server set
up now, so I have a bit more freedom and flexibility. I have a policy that
is basically working, and wanted to get some feedback on it.
I'm working on designing a security architecture for a Web application we
have under development, and creating an SELinux policy to help implement it.
I would like to prevent any flaws in Apache or the Web application from
leaking access to other HTTP worker processes for current or future
connections, where credentials of other users may be accessible.
The Web server begins in the httpd_t domain, which has somewhat more
privileges than our application needs. For example it has access to the
listening HTTP socket, where it could accept new connections and so access
future connections. I would like to reduce the privileges of the HTTP
worker processes after the connection is accepted but before any user data
has been processed or our application code has been executed.
I have this working with some mod_perl code which hooks into Apache right
after it accepts the connection, and changes its running domain to
httpd_portal_app_t. I did this by allowing a dyntransition from httpd_t to
httpd_portal_app_t, then writing the new context to "/proc/$$/attr/current",
and verified it is working with ps -Z. That domain has a smaller set of
privileges than httpd_t, and is not allowed to do things like accept new
connections, listen on new sockets, read from log files, etc. There is no
rule allowing httpd_portal_app_t to transition back to httpd_t, and after
handling a single connection, the process exits (it is configured with the
Apache option MaxRequestsPerChild 1).
I am still testing and prototyping, but so far this is all working. I have
a few questions, though.
First, I see a lot of warnings in "SELinux by example" and other places on
the Web about how using dyntransition is a bad idea. Is that true in this
case, and if so is there a better way to get a similar degree of isolation
without taking the performance hit that a CGI-based environment would cost?
Second, in RHEL 5, is there a way to constrain my httpd_portal_app_t to have
its permission set bounded by that of httpd_t? That is, so
that httpd_portal_app_t cannot have any privileges that httpd_t does not
have? I see that some versions of SELinux are able to enforce this with the
"typebounds" command, but that doesn't seem to be available in RHEL 5? That
would help me ensure that this domain could only make things more secure,
not less.
Third, since my main goal here is to prevent processes from interacting with
each other inappropriately, I would like to prevent each HTTP worker from
reading any information from "/proc" for other HTTP workers. Currently they
are allowed to do this, because they all run in the same domain. Is there
any way to prevent this?
Finally, if anybody has any thoughts or suggestions from doing similar
applications, your thoughts are appreciated.
Thanks!
-----Scott.
12 years, 9 months
AW: selinux Digest, Vol 84, Issue 10
by Andreas Bolatzki
Finally I found the problem: The .fc file was really still using the ubuntu directory structure (/usr/bin/virtualbox) unfortunately I didn't notice that this was different from the locations /usr/bin/ and /usr/lib/virtualbox where I found the binaries in question. --> blind me! :-(
Thanks a lot for he help!
>-----Ursprüngliche Nachricht-----
>Von: selinux-bounces(a)lists.fedoraproject.org [mailto:selinux-bounces@lists.fedoraproject.org] Im Auftrag von selinux->request(a)lists.fedoraproject.org
>Gesendet: Dienstag, 22. Februar 2011 13:00
>An: selinux(a)lists.fedoraproject.org
>Betreff: selinux Digest, Vol 84, Issue 10
> 4. Re: need to superseed default file context for virtualbox
> files but no method works (Dominick Grift)
>
>Message: 4
>Date: Mon, 21 Feb 2011 16:22:42 +0100
>From: Dominick Grift <domg472(a)gmail.com>
>Subject: Re: need to superseed default file context for virtualbox
> files but no method works
>To: selinux(a)lists.fedoraproject.org
>Message-ID: <4D628342.8070102(a)gmail.com>
>Content-Type: text/plain; charset=ISO-8859-1
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>>On 02/21/2011 04:15 PM, Andreas Bolatzki wrote:
>> Hello All
>>
>> I am working on Fedora 13 and VirtualBox 3.2
>>
>> Currently I try to apply a selinux module that has been created with
>> ubuntu to Fedora 13. Because I believe I understand what it should do I
>> just tried to make it run under F-13.
>> I have three files: vbox.te, vbox.if, vbox.fc to create a policy module.
>>
>> After making the vbox.pp I can load it with "semodule -I vbox.pp" and
>> the module shows up in semodule -l correctly.
>> The motivation to change these file-contexts is to prepare for correct
>> type-transition rules so they match the defined rules.
>>
>> Unfortunately the file-context is never set as needed and as described
>> in the vbox.fc.
>>
>> When I check .../file_contexts the correct statements are included but
>> they happen to appear later than something that was there before... (or
>> is there if the module is removed):
>> # matchpathcon /usr/lib/virtualbox/
>> /usr/lib/virtualbox system_u:object_r:lib_t:s0
>> # matchpathcon -f f13vbox.fc /usr/lib/virtualbox/
>> /usr/lib/virtualbox <<none>>
>>
>> Next I tried to do it with semanage fcontext -t
>> [~]$ sudo semanage fcontext -a -t vbox_manage_exec_t
>> /usr/lib/virtualbox/VboxManage
>> [~]$ ls -lZ /usr/lib/virtualbox/VBoxManage
>> -rwxr-xr-x. root root system_u:object_r:lib_t:s0
>> /usr/lib/virtualbox/VBoxManage
>That semanage command above only adds a new file context specification.
>You have to restore the context after that to actually apply the
>specified file context.
>
ANDREAS: OK The problem is that something supersedes my module!
ANDREAS:The restorecon does nothing first...
ANDREAS: [~]# restorecon -v /usr/lib/virtualbox/VBoxSDL
ANDREAS: [~]# chcon -t vbox_vbox_exec_t /usr/lib/virtualbox/VBoxSDL
ANDREAS: [~]# restorecon -v /usr/lib/virtualbox/VBoxSDL
ANDREAS:restorecon reset /usr/lib/virtualbox/VBoxSDL context system_u:object_r:vbox_vbox_exec_t:s0->system_u:object_r:lib_t:s0
ANDREAS: [~]#
ANDREAS: --->> Finally I found the problem: The .fc file was really still using the ubuntu directory structure (/usr/bin/virtualbox) unfortunately I didn't notice that this was different from /usr/bin/ and /usr/lib/virtualbox where I found the binaries in question. --> blind me! :-(
Thanks a lot for the help!
>
>> I 'd expect that the lib_t is replaced by vbox_manage_exec_t.
>> What is the problem? My understanding of what should happen might be
>> wrong...
>>
>> Thanks for your answers.
>>
>> Andreas
>>
>> ---
>> Conftents of vbox.fc
>> /dev/vboxdrv
>> gen_context(system_u:object_r:vbox_run_t,s0)
>> /dev/vboxnetctl
>> gen_context(system_u:object_r:vbox_run_t,s0)
>> /usr/lib/virtualbox
>> gen_context(system_u:object_r:vbox_run_t,s0)
>> /usr/lib/virtualbox/(.*)
>> gen_context(system_u:object_r:vbox_run_t,s0)
>> /usr/lib/virtualbox/VBoxManage --
>> gen_context(system_u:object_r:vbox_manage_exec_t,s0)
>> /usr/lib/virtualbox/VBoxXPCOMIPCD --
>> gen_context(system_u:object_r:vbox_ipc_exec_t,s0)
>> /usr/lib/virtualbox/VirtualBox --
>> gen_context(system_u:object_r:vbox_vbox_exec_t,s0)
>> /usr/lib/virtualbox/VBoxSDL --
>> gen_context(system_u:object_r:vbox_vbox_exec_t,s0)
>> /usr/lib/virtualbox/VBoxSVC --
>> gen_context(system_u:object_r:vbox_svc_exec_t,s0)
>> HOME_DIR/.VirtualBox(/.*)?
>> gen_context(system_u:object_r:vbox_run_t,s0)
>
>These are specified file contexts. After loading these, you may need to
>apply them by running restorecon on each of the paths
>
12 years, 9 months
semodule -b base.pp -- Segmentation fault.
by Kurian Thayil
Hi All,
Im a newbie in SELinux. Running RHEL 5 in a virtualized environment (RHEL 6
as host). I was trying to compile a base module with MONOLITHIC=n. While
doing semodule -b base.pp, it gives me a segmentation fault. This guest has
a memory of 1GB. Any idea why this happens?
Regards,
Kurian.
12 years, 9 months
Restrict unconfined_u access to a dir in targed mode
by Matthew Davis
Is it possible? I'm curious if you can restrict root from accessing a
given directory and limit it to a specific domain. Maybe this isn't
how targeted policy was designed, and the strict policy is needed. But
I was curious, and couldn't figure out a good way to do it.
12 years, 9 months
need to superseed default file context for virtualbox files but no method works
by Andreas Bolatzki
Hello All
I am working on Fedora 13 and VirtualBox 3.2
Currently I try to apply a selinux module that has been created with
ubuntu to Fedora 13. Because I believe I understand what it should do I
just tried to make it run under F-13.
I have three files: vbox.te, vbox.if, vbox.fc to create a policy module.
After making the vbox.pp I can load it with "semodule -I vbox.pp" and
the module shows up in semodule -l correctly.
The motivation to change these file-contexts is to prepare for correct
type-transition rules so they match the defined rules.
Unfortunately the file-context is never set as needed and as described
in the vbox.fc.
When I check .../file_contexts the correct statements are included but
they happen to appear later than something that was there before... (or
is there if the module is removed):
# matchpathcon /usr/lib/virtualbox/
/usr/lib/virtualbox system_u:object_r:lib_t:s0
# matchpathcon -f f13vbox.fc /usr/lib/virtualbox/
/usr/lib/virtualbox <<none>>
Next I tried to do it with semanage fcontext -t
[~]$ sudo semanage fcontext -a -t vbox_manage_exec_t
/usr/lib/virtualbox/VboxManage
[~]$ ls -lZ /usr/lib/virtualbox/VBoxManage
-rwxr-xr-x. root root system_u:object_r:lib_t:s0
/usr/lib/virtualbox/VBoxManage
I 'd expect that the lib_t is replaced by vbox_manage_exec_t.
What is the problem? My understanding of what should happen might be
wrong...
Thanks for your answers.
Andreas
---
Conftents of vbox.fc
/dev/vboxdrv
gen_context(system_u:object_r:vbox_run_t,s0)
/dev/vboxnetctl
gen_context(system_u:object_r:vbox_run_t,s0)
/usr/lib/virtualbox
gen_context(system_u:object_r:vbox_run_t,s0)
/usr/lib/virtualbox/(.*)
gen_context(system_u:object_r:vbox_run_t,s0)
/usr/lib/virtualbox/VBoxManage --
gen_context(system_u:object_r:vbox_manage_exec_t,s0)
/usr/lib/virtualbox/VBoxXPCOMIPCD --
gen_context(system_u:object_r:vbox_ipc_exec_t,s0)
/usr/lib/virtualbox/VirtualBox --
gen_context(system_u:object_r:vbox_vbox_exec_t,s0)
/usr/lib/virtualbox/VBoxSDL --
gen_context(system_u:object_r:vbox_vbox_exec_t,s0)
/usr/lib/virtualbox/VBoxSVC --
gen_context(system_u:object_r:vbox_svc_exec_t,s0)
HOME_DIR/.VirtualBox(/.*)?
gen_context(system_u:object_r:vbox_run_t,s0)
---
12 years, 9 months
Rawhide AVC denials
by Clyde E. Kunkel
Lots of denials from various pgms on /. Up to 24 denials just after a
reboot. Have bz'd some of them. Can't use List All Alerts button
(bz'd). ls -ldZ / shows:
dr-xr-xr-x. root root system_u:object_r:logrotate_t:s0 /
logrotate_t:s0 was an attempt on my part to fix one of the denials, is
it causing all of the denials?
Any ideas on what is going on? Just ignore and let rawhide settle down?
Running rawhide up-to-date (seeing same thing in F15 Alpha also) and
SeLinux in permissive mode.
TIA
--
Regards,
OldFart
12 years, 9 months
systemd to require selinux-policy?
by Dominick Grift
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Today when i wanted to uninstall selinux-policy in rawhide i noticed
that systemd requires selinux-policy.
I have not tested that thoroughly but could it be that rawhide stops
working properly if selinux=0?
I did have issues with systemd starting the network but i am not sure
whether its related to aforementioned, that maybe the cable was not
plugged in properly or that it was because the policy un-install/upgrade
went wrong.
But anyway's systemd requiring selinux-policy seems pretty radical.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk1ZmtoACgkQMlxVo39jgT9D1gCfViDWhwRXdo42oSijPm5gJT1y
VxUAoJ57bYap7W50KsO0BxqU3w5vHmSn
=H4ye
-----END PGP SIGNATURE-----
12 years, 9 months
