OpenOffice.org 1.9.100
by Aurelien Bompard
Hi,
Just so that you know, the OpenOffice 1.9.100 rpms from www.openoffice.org
won't run on FC3 because of SELinux:
audit(1115968252.998:0): avc: denied { execmod } for pid=9833
comm=soffice.bin
path=/opt/openoffice.org1.9.100/program/libicudata.so.26.0.1 dev=sda2
ino=308509 scontext=user_u:system_r:unconfined_t
tcontext=system_u:object_r:usr_t tclass=file
What should we tell the upstream rpm maintainters so that their packages
work on FC3 ? The packages used to work in an earlier version (1.9.73 I
think). It's also possible that a policy update caused it, I'm not sure, I
didn't use them very often.
Is there something we can do to fix it, or is it only in the hands of the
upstream maintainers ?
Thanks
Aurélien
--
http://gauret.free.fr ~~~~ Jabber : abompard(a)jabber.fr
I am the "ILOVEGNU" signature virus. Just copy me to your signature.
This email was infected under the terms of the GNU General Public License.
19 years, 1 month
Re: Untrusted content domain
by Ivan Gyurdiev
On Mon, 2005-05-09 at 14:04 +0100, Mike Hearn wrote:
> Hi Ivan,
>
> I saw your work on the restricted $HOME SELinux policy and this
> interests me a great deal (both with my Codeweavers hat and my
> autopackage hat on).
>
> I'd like to discuss this in a more public forum. Is the Fedora SELinux
> list a good place to talk about this sort of lockdown?
Ok. Basically my plan is to see how SELinux can be used to confine all
applications, including various "desktop" programs - content
handlers and such. I dislike how so many things that are completely
unrelated are marked ROLE_home_t under /home, and a lot of things
are marked ROLE_tmp_t under /tmp. I think there should be better
labeling of /home, and /tmp.
As part of this, I have suggested various changes, including:
- per domain labeling of ORBit sockets in /tmp, so apps
don't have to access ROLE_tmp_t
- confining various GNOME daemons to make use of this -
starting with GConf, and gnome-vfs-daemon
- labeling of the various GNOME hidden folders in /home with
a more specific context than ROLE_home_t
- restricting mozilla and other programs that interact with
the web to writing ROLE_untrusted_content_t, as opposed to ROLE_home_t
(or something stranger, like ROLE_mozilla_home_t, which is the current
behavior)
- labeling per/user fonts, and .desktop files, and writing macros
to make those work
- in the future, content-specific types such as ROLE_media_content_t,
that content handlers can access.
I have a bug tracking this here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155800
although right now this is just one large patch, not nearly where
it should be, and unsuitable for merging. I have sent Daniel Walsh
several smaller patches to begin implementing this - I need to update
the bug to reflect that, since the large patch is a bit out of date.
===========================
The untrusted_content part of this is a proposal for a type to be used
to mark things downloaded from the Internet that cannot be trusted
(hence..untrusted). The idea is that various web browsers, p2p clients,
etc. will use this type to store content.
Then the user would have to perform some sort of action to interact
with this type, to make it accessible by other programs. This
would be simply to relabel the file to a different type to begin with,
but in the future an automated mechanism could be used to do this,
or selinux integration with nautilus could be used to relabel the
files. There were also suggestions of a virus scan before
such content type would be made accessible.
Basically, for starters I just want better labeling of content
downloaded by mozilla, because ROLE_mozilla_home_t is just wrong - it's
the same type as is used for internal mozilla settings (.mozilla).
Then after the type exists, we can figure out what to do with it.
To make this work I wanted there to be a folder in /home
called downloads or something like that created by default.
Then things stored there would automatically get the right type.
I suggested that the GNOME team create such a folder, and integrate it
with the Places menu, but I don't think there was a lot of interest
on the Usability list - in any case people disagree about what
it should be called, or whether it's important to have such a folder.
I haven't decided what to do about this - currently my patch simply
labels downloads and ".*Downloads" as ROLE_untrusted_content_t,
if they are present. It also changes the type of files saved by mozilla
in tmp to ROLE_untrusted_content_t.
19 years, 1 month
targeted/cups.te - unconfined_t send_msg....
by Tom London
Running targeted/enforcing, latest rawhide.
I get the following avc during login:
May 11 06:18:09 localhost dbus: avc: denied { send_msg } for
msgtype=method_call interface=com.redhat.CupsDriverConfig
member=MatchDriver dest=com.redhat.CupsDriverConfig spid=3675
tpid=3019 scontext=user_u:system_r:unconfined_t
tcontext=system_u:system_r:cupsd_config_t tclass=dbus
Does this make sense?
--- cups.te 2005-05-02 13:18:00.000000000 -0700
+++ /tmp/cups.te 2005-05-11 07:38:05.000000000 -0700
@@ -258,5 +258,5 @@
can_unix_connect(cupsd_t, initrc_t)
allow cupsd_t initrc_t:dbus send_msg;
allow initrc_t cupsd_t:dbus send_msg;
-allow cupsd_t unconfined_t:dbus send_msg;
+allow { cupsd_t cupsd_config_t } unconfined_t:dbus send_msg;
')
tom
--
Tom London
19 years, 1 month
Re: using selinux to control user access to files
by Steve G
>I take it that even if I fire up auditd on RHEL4 today, and attempt to
>play with auditctl, it isn't going to work until there is updated kernel
>(or I patch/recompile existing kernel)?
Right. There's roughly 20-30 patches against the RHEL4 kernel at this point. Some
of which are experimental and not accepted upstream and therefore likely to
change. FC4 has everything in it that is currently accepted upstream. It would be
easier to experiment with FC4 at this point.
-Steve
__________________________________
Yahoo! Mail Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
http://mobile.yahoo.com/learn/mail
19 years, 1 month
Re: using selinux to control user access to files
by Steve G
>In my work environmnt, we work with some sensitive data, and we must have audit
>trail whenever some types of files are touched (or we would fail external
audits,
>which translates to lost jobs, simple as that). Problem with using Linux so far
>was lack of good auditing tools.
This is all in work. The 0.7.4 audit package has some information about setting
file watches (auditctl -w -p ). However, you need to have a kernel that's patched
for it. We are still peer reviewing this capability. I think we have just a few
more locking issues to solve and then it will be sent to lkml. I have put the
tools into FC4 so that when the file system auditing patch does go upstream & you
do a kernel update, everything starts working.
-Steve Grubb
__________________________________
Yahoo! Mail Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
http://mobile.yahoo.com/learn/mail
19 years, 1 month
Re: using selinux to control user access to files
by Steve G
>A bit missing in documentation on RHEL4, however I fetched sources from rawhide
>(that have some documentation).
At the time tha RHEL4 shipped, the audit framework had a lot of work to go. It
couldn't really be documented since the utilities didn't really exist. It is
slated for inclusion in U2. Also, FC4 has a respectable piece of the audit
subsystem in it.
>Is Audit Framework part of SELinux, used by SELinux, or something totally
>unrelated?
Its a separate entity with a different control interface. SE Linux uses it to
send AVC messages. The audit system determines whether an audit daemon is in use.
If so the messages go to the audit daemon. If not, they go to syslog.
If you want to experiment with the audit system, try out FC4. I'll probably start
writing tutorials and howto's once the audit system gets closer to completion.
-Steve Grubb
__________________________________
Yahoo! Mail Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
http://mobile.yahoo.com/learn/mail
19 years, 1 month
nss_ldap's tls_key file permission
by Farkas Levente
hi,
if we'd like to use nss_ldap with tls certificzte files than we have to
use a least 644 permission even on the key file. it's not a good
security concern. it's better than without tls, but local user still too
powerful in this case:-( is there any way to prevent this? i mean to be
able to change the file permission to root:root 640 and use nss_ldap
too? usualy in this case a small portion of the progam run as setuid
root, but of course in this case it can't help since it's a library and
the whole nss philosophy are different from this. what can i do? or
currently there is no solution for this?
thanks in advance.
yours.
--
Levente "Si vis pacem para bellum!"
19 years, 1 month
CGI on user directory
by Yuichi Nakamura
On FC4 test2 with targeted policy(selinux-policy-targeted-1.23.14-2),
I tried to run CGI on user home directory.
After checked it run on permissive mode,
chcon like following.
chcon -R system_u:object_r:httpd_sys_script_exec_t ~/public_html/cgi-bin/
I found it does not work on enforcing mode.
After I add "allow httpd_suexec_t user_home_t:dir { read };"
it worked.
Please add it to apache.te
---
Yuichi Nakamura
19 years, 1 month
Re: gpg through apache and php?
by brett
>
> If you organize your /var/www
> tree in a conventional manner, then it should work fairly smoothly.
> Problems arise when people put CGIs all over the place (not just in cgi-
> bin), and don't use any conventions in separating files that should be
> read-only vs. read-write.
OK, you are selling me on the /var/www tree. What is "a conventional
manner." Needless to say you don't have to explain it all to me, perhaps
you can point me to a resource that describes what you are talking about.
For example, where do user PHP scripts live in this tree? Are they
readable\writable by others?
> Simplest thing to do is just to install policy sources and just allow
> the permissions you want, e.g.
> yum install selinux-policy-targeted-sources
> cd /etc/selinux/targeted/src/policy
> repeat:
> audit2allow -d >> domains/misc/local.te
> make load
> <retry operation>
> <goto repeat if it fails>
>
> Might be quicker to switch to permissive mode (setenforce 0), run your
> CGI via apache, then run audit2allow once, as that will then collect
> _all_ of the audit messages that would have been denied in enforcing
> mode.
So selinux-policy-targeted-sources is something that lets me change
policy?
And audit2allow is something that monitors what processes are open and
"allows" them to pass through SELinux?
Thanks,
-brett
19 years, 1 month
