Re: Desktop apps interoperability
by Casey Schaufler
--- Tom <tom(a)lemuria.org> wrote:
> On Mon, Mar 28, 2005 at 12:27:31AM -0500, Ivan
> Gyurdiev wrote:
> > Part of the problem seems to be the way Linux apps
> treat /home, as the
> > place for everything.
>
> It doesn't. It treats $HOME as the only place that
> the user has
> permission to store his stuff. On a well-configured
> system, that
> assumption is correct.
Windows and MacOS are designed as single user systems.
Unix and Linux are designed as multiuser systems.
Configuring a Windows system for multiple
concurrent users is quite painful. Configuring
unix for a single user seems unnecessarily difficult.
Interestly, when we did the B1/LSPP versions of
unix the home directory model helped reduce the
problem of user sensitivity restrictions by
isolating the part of the directory hierarchy
that had to be customized for the user.
Casey Schaufler
casey(a)schaufler-ca.com
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
19 years, 1 month
selinux error and kernel lockups
by Justin Conover
The last 3 kernels in rawhide have hung my box on reboot with this
being the last error i see on screen:
SELinux: initialized (dev binfmt_misc, type binfmt_misc), uses genfs_contexts
Any ideas?
Kernel-1177 works fine
I get the error with these 3
1191
1202
1208
19 years, 1 month
Re: Fedora Core 3 Test Update: kernel-2.6.11-1.7_FC3
by Ivan Gyurdiev
On Mon, 2005-03-28 at 14:31 +0200, Aurelien Bompard wrote:
> Ivan Gyurdiev wrote:
>
> > On Mon, 2005-03-28 at 13:46 +0200, Aurelien Bompard wrote:
> >> Ivan Gyurdiev wrote:
> >> > On Mon, 2005-03-28 at 12:55 +0200, Aurelien Bompard wrote:
> >> >> Dave Jones wrote:
> >> >> > Product : Fedora Core 3
> >> >> > Name : kernel
> >> >> > Version : 2.6.11
> >> >> > Release : 1.7_FC3
> >> >>
> >> >> With this kernel, snmpd fails to start, probably due to a selinux
> >> >> error : snmpd: /usr/sbin/snmpd: error while loading shared libraries:
> >> >> libbeecrypt.so.6: cannot enable executable stack as shared object
> >> >> requires: Permission denied
> >> >
> >> > Are there any related avc messages in the log (dmesg) ?
> >>
> >> Yes:
> >> audit(1112010219.531:0): avc: denied { execmem } for pid=4806
> >> comm=snmpd scontext=user_u:system_r:snmpd_t
> >> tcontext=user_u:system_r:snmpd_t tclass=process
> >
> > I don't get this denial on rawhide - maybe it was fixed.
> > See if there is an allow_execmem boolean, and enable that to
> > work around the denial.
>
> Thanks, but the only boolean about snmp on FC3 is snmpd_disable_trans.
> Could we have a selinux update too if this kernel is pushed to the official
> updates ?
cc-ed fedora-selinux-list.
--
Ivan Gyurdiev <ivg2(a)cornell.edu>
Cornell University
19 years, 1 month
libicudata.so.26.0, prelink, symbolic link, ...
by Tom London
Running targeted/enforcing, latest rawhide.
Noticed the following AVC in log:
Mar 25 07:38:36 localhost kernel: audit(1111765116.214:0): avc:
denied { execmod } for pid=13994 comm=ld-linux.so.2
path=/usr/lib/openoffice.org1.9.87/program/libicudata.so.26.0 dev=dm-0
ino=164963 scontext=user_u:system_r:crond_t
tcontext=system_u:object_r:lib_t tclass=file
This appears to be generated by prelink run from cron.
Here are entries from prelink.log:
Prelinking /usr/lib/openoffice.org1.9.87/program/libicudata.so.26.0
/usr/sbin/prelink:
/usr/lib/openoffice.org1.9.87/program/libicudata.so.26.0 Could not
trace symbol resolving
/usr/sbin/prelink: Could not prelink
/usr/lib/openoffice.org1.9.87/program/libicuuc.so.26.0 because its
dependency /usr/lib/openoffice.org1.9.87/program/libicudata.so.26.0
could not be prelinked
/usr/sbin/prelink: Could not prelink
/usr/lib/openoffice.org1.9.87/program/libicule.so.26.0 because its
dependency /usr/lib/openoffice.org1.9.87/program/libicuuc.so.26.0
could not be prelinked
Prelinking /usr/lib/openoffice.org1.9.87/program/libjvmaccessgcc3.so.3
/usr/sbin/prelink: Could not prelink
/usr/lib/openoffice.org1.9.87/program/libvcl680li.so because its
dependency /usr/lib/openoffice.org1.9.87/program/libicuuc.so.26.0
could not be prelinked
<<<< etc. >>>
Interestingly, the AVC seems to be showing the the type of the link
instead of the type of the real file:
[root@tlondon program]# ls -lZ libicudata*
lrwxrwxrwx root root system_u:object_r:lib_t
libicudata.so -> libicudata.so.26.0
lrwxrwxrwx root root system_u:object_r:lib_t
libicudata.so.26 -> libicudata.so.26.0
-r--r--r-- root root system_u:object_r:shlib_t
libicudata.so.26.0
Any significance to this?
tom
--
Tom London
19 years, 1 month
Re: append only file system - selinux?
by Colin Walters
On Thu, 2005-03-24 at 15:58 -0500, Chris Stankaitis wrote:
> If there is no 2.4 kernel solution, is there a 2.6/selinux solution to
> my problem? that would not allow anyone (even root) to do anything but
> append to logs?
Yes, definitely. SELinux provides a fine-grained "append" permission
for files that one can grant to specific domains for specific file types
(such as log files).
How exactly you implement this depends on which threats you are trying
to counter. If you are simply trying to prevent a compromised daemon
program which runs as uid 0 from changing logs, you could probably stick
with the default Fedora "targeted" policy, which for a number of daemons
such as Apache HTTPD already enforces this restriction. If you have
daemons outside the targeted set, it is typically not too difficult to
pull in the relevant policy from the "strict" into targeted, although
there are a few gotchas which we can help with on fedora-selinux-list.
In order to confine user logins (e.g. someone logging in as root via
sshd), you will need to use the "strict" policy. You then have to make
a decision on exactly what permissions to grant to the login. One
option is to simply place root into the user_r role (i.e. not sysadm_r).
There, the login is restricted in a way similar in effect to a Linux
non-zero uid. However, system administration such as restarting daemons
is not possible.
It is theoretically possible to have a role similar to sysadm_r/sysadm_t
but that prevents direct access to log files. However, it seems very
likely to me that someone with privileges similar to sysadm_t could
indirectly influence log files in other ways; e.g. by simply installing
a malicious version of a daemon package. I imagine the same is true of
the BSD securitylevel, of course.
One nice thing about SELinux though is that you can use a tool such as
"apol" to find all of those means of influence; i.e. what is the
information flow from user_t to httpd_log_t. With BSD security levels
you don't have any such assurance.
If you have more questions about SELinux, please ask on
fedora-selinux-list.
19 years, 1 month
(newbie)Troubles with SE-Linux
by Paul Rumin
I would like to preface this with "I am not new to linux, but new to
SE-Linux." I am not sure where to begin with this problem. After a
clean install of Fedore Core 3 (at least I thought clean), I tried to
login in with a user account a few days later. This did not work, so
I logged in as root to change my user's password.
1. First, I tried changing the user's password with passwd. Although
the program seemed to accept the new password. I still was unable to
login in afterwards.
2. So I tried to manually change it within the /etc/passwd file.
Knowing that there was a shadow file, I deleted the encrypted
password in shadow and the "x" in the /etc/password file. Then, I ran
passwd, followed by pwconv. But still nothing.
3. Finally, I tried to just use "su" command into my user's account
to no avail.
Now I am stuck. My understanding of SE is that you must match
securities contents of the files, by using the -Z delimiter, which I
did verify.
If someone could steer me in the right direction I would appreciate it.
Thx,
Paul
BTW, I did also try userdel/useradd with no success.
19 years, 1 month
system-config-printer/cups: unconfined_t:fifo_file {read write} ?
by Tom London
Running targeted, latest development stuff.
Configuring a 'new' USB printer from 'Desktop->System
Settings->Printing' produces a wealth of avcs like:
Mar 23 08:08:14 localhost kernel: audit(1111594094.345:0): avc:
denied { read } for pid=19983 exe=/usr/sbin/cupsd path=pipe:[194059]
dev=pipefs ino=194059 scontext=root:system_r:cupsd_t
tcontext=root:system_r:unconfined_t tclass=fifo_file
Mar 23 08:08:14 localhost kernel: audit(1111594094.345:0): avc:
denied { write } for pid=19983 exe=/usr/sbin/cupsd
path=pipe:[194059] dev=pipefs ino=194059
scontext=root:system_r:cupsd_t tcontext=root:system_r:unconfined_t
tclass=fifo_file
Appears to be asking for
allow cupsd_t unconfined_t:fifo_file { read write };
This denial appears not to cause a problem, since the printer works.
Should this be a 'dontaudit'? Something else (like a missing
transition)?
thanks,
tom
--
Tom London
19 years, 1 month
Re: SELinux policy for ndiswrapper
by Ryan Gall
> > > > #Context for the driver configuration files
> > > > /etc/ndiswrapper/ -- system_u:object_r:loadndis_content_t
> > >
> > > you probably want this:
> > >
> > > /etc/ndiswrapper(/.*)? system_u:object_r:loadndis_content_t
> > >
> > > so you can label all of the driver stuff tha'ts stored under that
> > > directory and it's subdirectories. I don't think your pattern will
> > > match anything.
> > >
> > Actually everything does get the correct labels here. I guess it is
> > setting the label on the ndiswrapper directory and then all the child
> > directories and files are inheriting that context.
>
> Well if the directory is labeled correctly, and files are created in
> that directory, then it would get loadndis_content_t. However, if you
> relabeled, I bet they would end up having the wrong labels. Try running
> matchpathcon on a file in /etc/ndiswrapper, to see what file context
> matches. (`matchpathcon /etc/ndiswrapper/somefile`).
>
> --
> Chris PeBenito
> Tresys Technology, LLC
> (410) 290-1411 x150
>
You were right Chris, it did not work correctly when I relabeled.
Thanks for all your help.
Ryan
19 years, 1 month
Recent SEL problems on FC3 box - named & dhcpd
by Ruth Ivimey-Cook
Hi folks,
I have just started having some problems with selinux. I'm using FC3 with the
targetted policy. It was running enforced; now merely permissive because of the
problems. The box is running BIND/named in master mode (i.e. it is master for
some domains, but not supplying those domains to other demons) and a dhcp
server. I have today used yum to update both daemons from the updates-released
repo, and am now getting errors of this sort (note this is a sample - there are
many more):
...
audit(1111501062.397:0): avc: denied { search } for pid=6809
exe=/usr/sbin/dhcpd name=/ dev=md1 ino=2 scontext=root:system_r:dhcpd_t
tcontext=system_u:object_r:file_t tclass=dir
audit(1111501062.397:0): avc: denied { search } for pid=6809
exe=/usr/sbin/dhcpd name=/ dev=md1 ino=2 scontext=root:system_r:dhcpd_t
tcontext=system_u:object_r:file_t tclass=dir
audit(1111501107.559:0): avc: denied { search } for pid=6828
exe=/usr/sbin/named name=/ dev=md1 ino=2 scontext=root:system_r:named_t
tcontext=system_u:object_r:file_t tclass=dir
...
audit(1111501250.295:0): avc: denied { write } for pid=6873
exe=/usr/sbin/named name=log dev=tmpfs ino=8452 scontext=root:system_r:named_t
tcontext=user_u:object_r:device_t tclass=sock_file
audit(1111501250.295:0): avc: denied { sendto } for pid=6873
exe=/usr/sbin/named path=/dev/log scontext=root:system_r:named_t
tcontext=user_u:system_r:unconfined_t tclass=unix_dgram_socket
audit(1111501302.433:0): avc: denied { search } for pid=6896
exe=/usr/sbin/dhcpd name=/ dev=md1 ino=2 scontext=root:system_r:dhcpd_t
tcontext=system_u:object_r:file_t tclass=dir
audit(1111501302.433:0): avc: denied { search } for pid=6896
exe=/usr/sbin/dhcpd name=etc dev=md1 ino=1368193 scontext=root:system_r:dhcpd_t
tcontext=root:object_r:file_t tclass=dir
audit(1111501302.437:0): avc: denied { read } for pid=6896
exe=/usr/sbin/dhcpd name=libc.so.6 dev=md1 ino=295646
scontext=root:system_r:dhcpd_t tcontext=root:object_r:file_t tclass=lnk_file
...
Using audit2allow on the full set gives the following:
allow dhcpd_t device_t:sock_file write;
allow dhcpd_t file_t:dir { add_name search write };
allow dhcpd_t file_t:file { append create execute getattr link read unlink
write };
allow dhcpd_t file_t:lnk_file read;
allow dhcpd_t unconfined_t:unix_dgram_socket sendto;
allow named_t device_t:sock_file write;
allow named_t file_t:dir search;
allow named_t file_t:file { execute getattr read };
allow named_t file_t:lnk_file read;
allow named_t unconfined_t:unix_dgram_socket sendto;
Now, would you expect that I should need to modify the settings?
Might it be appropriate to recompile the policy even though I've not changed it
myself?
I have also been seeing many avc:s from attempts to run rndc. The following
might be indicative (I just "prompted" these by doing service named status):
audit(1111505098.098:0): avc: denied { search } for pid=12690
exe=/usr/sbin/rndc name=/ dev=md1 ino=2 scontext=root:system_r:ndc_t
tcontext=system_u:object_r:file_t tclass=dir
audit(1111505098.114:0): avc: denied { search } for pid=12690
exe=/usr/sbin/rndc name=etc dev=md1 ino=1368193 scontext=root:system_r:ndc_t
tcontext=root:object_r:file_t tclass=dir
audit(1111505098.114:0): avc: denied { read } for pid=12690
exe=/usr/sbin/rndc name=ld.so.cache dev=md1 ino=1370938
scontext=root:system_r:ndc_t tcontext=root:object_r:file_t tclass=file
audit(1111505098.114:0): avc: denied { getattr } for pid=12690
exe=/usr/sbin/rndc path=/etc/ld.so.cache dev=md1 ino=1370938
scontext=root:system_r:ndc_t tcontext=root:object_r:file_t tclass=file
audit(1111505098.114:0): avc: denied { read } for pid=12690
exe=/usr/sbin/rndc name=libcrypto.so.4 dev=md1 ino=211792
scontext=root:system_r:ndc_t tcontext=root:object_r:file_t tclass=lnk_file
audit(1111505098.118:0): avc: denied { execute } for pid=12690
path=/lib/libcrypto.so.0.9.7a dev=md1 ino=214229 scontext=root:system_r:ndc_t
tcontext=root:object_r:file_t tclass=file
19 years, 1 month
[newbie] YUM hangs, can't update without reboot with selinux=0
by John Johnson
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello Everyone!
Apologies for my lack of knowledge. If you are inclined to reply RTFM!,
by all means do so, but include a link to TFM, please :-)
When I run YUM, it runs briefly, then just sits there. Even when I do
'setenforce 0'. If I reboot with selinux=0 and the command line, it
works. I can't find any complaints in any logs (tips on this
appreciated too). Is there a way to allow updates without two complete
shutdowns plus a file fix?
Thanks in advance,
JJ
Fedora Core release 3 (Heidelberg)
Linux www.johnjohnson.info 2.6.10-1.770_FC3 #1 Thu Feb 24 14:00:06 EST
2005 i686 i686 i386 GNU/Linux
yum version 2.2.0
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFCPtrB56Q2CqQ+d1wRAqdEAJ9EnOPtQ++Jmx9GsogIPmBj7hGrCQCdEST7
z6Hf/C3zcUKiZXQauhKEgLs=
=Jx9V
-----END PGP SIGNATURE-----
19 years, 1 month
