Problem getting samba share running
by Knute Johnson
No matter what I try, I keep getting a selinux error when I create a
share in my home directory. I've enabled home directories and set
read/write in the booleans, I've set the directory to rw for all
users, and I've tried several different contexts, samba_share_t,
public_content_rw_t and at least one other with the same results.
Here is the message I get:
avc: denied { read } for comm=nmbd dev=inotifyfs path=inotify
pid=3296 scontext=system_u:system_r:nmbd_t:s0 tclass=dir
tcontext=system_u:object_r:inotifyfs_t:s0
I've looked at the tutorials and they all apparently lack some vital
information that 'every body knows' except me :-).
Any help would be appreciated.
Thanks,
--
Knute Johnson
Molon Labe...
16 years, 5 months
Mail from cron in Fedora 8
by Paul Howarth
I have a cron job as follows:
# crontab -l -u softlib
45 4 * * * /softlib/scripts/updates-sync | Mail -s "Fedora updates
subset mirror report" phowarth
The script runs reposync to pull in a subset of the updates repo, and I
have the output piped into Mail.
This has been trouble free up until I upgraded to F8, with
selinux-policy-3.0.8-44.fc8.
With SELinux in enforcing mode, the email I receive simply says
"/usr/sbin/sendmail: Permission denied".
I tried creating a local policy module as usual and ended up with this:
policy_module(localmisc, 0.0.7)
require {
type system_mail_t;
class netlink_route_socket { bind create getattr nlmsg_read
read write };
}
#============= system_mail_t ==============
allow system_mail_t self:netlink_route_socket { bind create getattr
nlmsg_read read write };
unconfined_read_tmp_files(system_mail_t)
In permissive mode, this works, but in enforcing mode I just get the
usual "Permission denied" message. There are no more avcs in the audit
logs, but there is this:
type=SELINUX_ERR msg=audit(1194605105.159:168): security_compute_sid:
invalid context unconfined_u:unconfined_r:system_mail_t:s0 for
scontext=unconfined_u:unconfined_r:unconfined_crond_t:s0
tcontext=system_u:object_r:sendmail_exec_t:s0 tclass=process
type=SYSCALL msg=audit(1194605105.159:168): arch=40000003 syscall=11
success=no exit=-13 a0=805848b a1=9cf82b8 a2=bfcbf338 a3=9cf82b8 items=0
ppid=1537 pid=1550 auid=4294967295 uid=1502 gid=1502 euid=1502 suid=1502
fsuid=1502 egid=1502 sgid=1502 fsgid=1502 tty=(none) comm="Mail"
exe="/bin/mail" subj=unconfined_u:unconfined_r:unconfined_crond_t:s0
key=(null)
I thought there might be something dontaudited so I tried using
enableaudit.pp but the F8 policy doesn't include this. What's the method
for finding troublesome dontaudits that need to be allows in F8?
Paul.
16 years, 5 months
audit2allow failure
by Gene Heskett
Greetings;
Running selinux in permissive mode, the /var/log/audit/audit.log was filling
up with squawks re cron jobs. Seeing an example on how to run audit2allow, I
thought I'd try it to see if that would shut the muttering up.
[root@coyote ~]# audit2allow -M local -i /var/log/audit/audit.log
compilation failed:
(unknown source)::ERROR 'syntax error' at token '' on line 6:
/usr/bin/checkmodule: error(s) encountered while parsing configuration
/usr/bin/checkmodule: loading policy configuration from local.te
I can't see anything different about line 6 of the log, but here is a head of
that file:
type=USER_ACCT msg=audit(1193734801.287:27922): user pid=11880 uid=0
auid=4294967295 msg='PAM: accounting acct=root : exe="/usr/sbin/crond"
(hostname=?, addr=?, terminal=cron res=success)'
type=CRED_ACQ msg=audit(1193734801.288:27923): user pid=11880 uid=0
auid=4294967295 msg='PAM: setcred acct=root : exe="/usr/sbin/crond"
(hostname=?, addr=?, terminal=cron res=success)'
type=USER_START msg=audit(1193734801.288:27924): user pid=11880 uid=0
auid=4294967295 msg='PAM: session open acct=root : exe="/usr/sbin/crond"
(hostname=?, addr=?, terminal=cron res=success)'
type=CRED_DISP msg=audit(1193734801.312:27925): user pid=11880 uid=0
auid=4294967295 msg='PAM: setcred acct=root : exe="/usr/sbin/crond"
(hostname=?, addr=?, terminal=cron res=success)'
type=USER_END msg=audit(1193734801.312:27926): user pid=11880 uid=0
auid=4294967295 msg='PAM: session close acct=root : exe="/usr/sbin/crond"
(hostname=?, addr=?, terminal=cron res=success)'
type=USER_ACCT msg=audit(1193734861.316:27927): user pid=11969 uid=0
auid=4294967295 msg='PAM: accounting acct=root : exe="/usr/sbin/crond"
(hostname=?, addr=?, terminal=cron res=success)'
type=CRED_ACQ msg=audit(1193734861.316:27928): user pid=11969 uid=0
auid=4294967295 msg='PAM: setcred acct=root : exe="/usr/sbin/crond"
(hostname=?, addr=?, terminal=cron res=success)'
contents of local.te:
------
module local 1.0;
EOF
------
The example command line shown above is I assume is correct, is it not?
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Operative (to Mal): "You can not make me angry."
Inara: "Please - spend an hour with him!"
--"Serenity"
16 years, 5 months
SMTP-AUTH
by John Griffiths
I am trying to use dovecot with postfix to provide smtp-auth. The
instructions provided by postfix http://www.postfix.org/SASL_README.html
works perfectly in Fedora Core 6.
Using the exact same procedure in Fedora 7 results in some conflicts
between dovecot_auth_t and postfix_private_t. Since using Dovecot for
SASL smtp-auth is the preferred way according to Postfix, I suspect
there must be something I am missing or maybe there is an oversight in
the policies.
Using sealert -l on the denial for dovecot results in:
Summary
SELinux is preventing /usr/libexec/dovecot/dovecot-auth
(dovecot_auth_t)
"write" to auth (postfix_private_t).
Detailed Description
SELinux denied access requested by
/usr/libexec/dovecot/dovecot-auth. It is
not expected that this access is required by
/usr/libexec/dovecot/dovecot-
auth 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
Sometimes labeling problems can cause SELinux denials. You
could try to
restore the default system file context for auth, restorecon -v
auth If this
does not work, there is currently no automatic way to allow this
access.
Instead, you can generate a local policy module to allow this
access - see
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
http://bugzilla.redhat.com/bugzilla/enter_bug.cgi
against this package.
Additional Information
Source Context system_u:system_r:dovecot_auth_t
Target Context root:object_r:postfix_private_t
Target Objects auth [ sock_file ]
Affected RPM Packages dovecot-1.0.5-15.fc7 [application]
Policy RPM selinux-policy-2.6.4-48.fc7
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name plugins.catchall_file
Host Name gei.internal.grifent.com
Platform Linux gei.internal.grifent.com
2.6.23.1-10.fc7 #1
SMP Fri Oct 19 15:39:08 EDT 2007 i686 i686
Alert Count 2
First Seen Wed Oct 31 03:39:55 2007
Last Seen Wed Oct 31 11:55:12 2007
Local ID 8b0a6068-b654-4151-b82e-c149d3b9d57b
Line Numbers
Raw Audit Messages
avc: denied { write } for comm="dovecot-auth" dev=dm-0 egid=0 euid=0
exe="/usr/libexec/dovecot/dovecot-auth" exit=-13 fsgid=0 fsuid=0
gid=0 items=0
name="auth" pid=2545 scontext=system_u:system_r:dovecot_auth_t:s0 sgid=0
subj=system_u:system_r:dovecot_auth_t:s0 suid=0 tclass=sock_file
tcontext=root:object_r:postfix_private_t:s0 tty=(none) uid=0
Dovecot writes a socket to /var/spool/postfix/private/auth with
permissions of 660. This is done when dovecot starts and on FC6, the
files is transitioned to be owned by postfix with a group of postfix.The
transition of owner/group does not happen of Fedora 7.
The auth socket is necessary to do smtp-auth.
Did I miss something in the configuration on Fedora 7?
Regards,
John
16 years, 5 months
gdm has problems with selinux or vice versa
by Antonio Olivares
Dear all,
after updating and getting the INIT: error that I had posted before, I can login by pressing enter and get X, however, when starting up I am greeted by setroubleshooter with some messages
[olivares@localhost ~]$ cat /etc/fedora-release
Fedora release 8.90 (Rawhide)
[olivares@localhost ~]$ date
Sun Nov 11 10:40:25 CST 2007
[olivares@localhost ~]$
I try to apply the fix suggested, but it does not seem to be working :(
Summary
SELinux is preventing gdm (xdm_t) "execute" to <Unknown> (rpm_exec_t).
Detailed Description
SELinux denied access requested by gdm. It is not expected that this access
is required by gdm 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
Sometimes labeling problems can cause SELinux denials. You could try to
restore the default system file context for <Unknown>, restorecon -v
<Unknown> If this does not work, there is currently no automatic way to
allow this access. Instead, you can generate a local policy module to allow
this access - see 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
http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package.
Additional Information
Source Context system_u:system_r:xdm_t:SystemLow-SystemHigh
Target Context system_u:object_r:rpm_exec_t
Target Objects None [ file ]
Affected RPM Packages
Policy RPM selinux-policy-3.0.8-44.fc8
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name plugins.catchall_file
Host Name localhost
Platform Linux localhost 2.6.23.1-42.fc8 #1 SMP Tue Oct 30
13:55:12 EDT 2007 i686 athlon
Alert Count 162
First Seen Sun 11 Nov 2007 09:11:06 AM CST
Last Seen Sun 11 Nov 2007 10:36:27 AM CST
Local ID f3168196-46ac-4951-ab61-b3b218534bb2
Line Numbers
Raw Audit Messages
avc: denied { execute } for comm=gdm dev=dm-0 name=rpm pid=8443
scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tclass=file
tcontext=system_u:object_r:rpm_exec_t:s0
Summary
SELinux is preventing gdm (xdm_t) "getattr" to /bin/rpm (rpm_exec_t).
Detailed Description
SELinux denied access requested by gdm. It is not expected that this access
is required by gdm 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
Sometimes labeling problems can cause SELinux denials. You could try to
restore the default system file context for /bin/rpm, restorecon -v /bin/rpm
If this does not work, there is currently no automatic way to allow this
access. Instead, you can generate a local policy module to allow this
access - see 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
http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package.
Additional Information
Source Context system_u:system_r:xdm_t:SystemLow-SystemHigh
Target Context system_u:object_r:rpm_exec_t
Target Objects /bin/rpm [ file ]
Affected RPM Packages rpm-4.4.2.2-7.fc9 [target]
Policy RPM selinux-policy-3.0.8-44.fc8
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name plugins.catchall_file
Host Name localhost
Platform Linux localhost 2.6.23.1-42.fc8 #1 SMP Tue Oct 30
13:55:12 EDT 2007 i686 athlon
Alert Count 180
First Seen Sun 11 Nov 2007 09:11:06 AM CST
Last Seen Sun 11 Nov 2007 10:36:27 AM CST
Local ID e1676a84-c6d0-45b8-97d7-c7cae2d755c1
Line Numbers
Raw Audit Messages
avc: denied { getattr } for comm=gdm dev=dm-0 egid=0 euid=0 exe=/bin/bash
exit=-13 fsgid=0 fsuid=0 gid=0 items=0 path=/bin/rpm pid=8443
scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 sgid=0
subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 suid=0 tclass=file
tcontext=system_u:object_r:rpm_exec_t:s0 tty=(none) uid=0
Thanks,
Antonio
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
16 years, 5 months
Fedora Core 7 Policy examples to trim root users rights
by Markus Rudel
Hello everybody,
I'm currently looking into SELinux on Fedora Core 7. Right now, I've
read "SELinux by Example" as well as several other documents on the
net. But no document covers Fedora 7.
Is there documentation especially made for Fedora 7?
My main goals in using SELinux are:
Trim root user rights:
root and normal users shouldn't be able to access other user files.
There should be one seperate user besides root, who can control and
grant access to SELinux rights. The examples from "SELinux by
Example" (page 309 to 311) don't work for me. the newrole command to
switch to user admin don't work.
Limiting access to insmod, lsmod etc. to avoid loading further kernel
modules (I know, the same effect could be accomplished by using a
static kernel, but I'm interested in limiting access to kernel modules
while using a modular kernel).
Limiting access to /dev/kmen to avoid reading memory
Maybe someone can help me with some example policies. I'm not so much
interested in restraining processes, right now, my only concern and
idea is to limit access to files and folders. This is because almost
everything under Linux works with files. So the idea is to control
access on just a few files. This would be very helpful for me.
Right now, I'm smacking my head on the table. After installing and
trying strict, refpolicy and mls policy, I'm stuck.
Thanks for your help
Markus
16 years, 5 months
audit fc6 and java
by selinux@lucullo.it
Hi guys.
i have an issue with samba. can someone help me?
i need to build a rule for this audit:
kernel: audit(1194422951.635:3): avc: denied { execmod }
for pid=3418 comm="java" name="libj9thr23.so" dev=hda2
ino=32148 scontext=system_u:system_r:initrc_t:s0
tcontext=system_u:object_r:usr_t:s0 tclass=file
is it possible?
thank you.
16 years, 5 months
selinux autorelabel and amanda
by Gene Heskett
Greetings;
I got bit pretty hard last night after installing 2.6.24-rc2, and it took
about an hour to relabel the whole system.
That was ok, and the logs are quieter now, but when it came time to run
amanda, the relabel had apparently changed the ctime of everything on the
system, so amanda tried to do all incrementals at level 0, and failed of
course because the vtape was only 1/4 the size of the system.
That flushed, and a couple more runs and it will be back to normal, but it
seems to me that there should be an option to preserve ctimes when
relabeling.
Is that even possible?
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The San Diego Freeway. Official Parking Lot of the 1984 Olympics!
16 years, 5 months
How to solve these audit messages
by Ali Nebi
Hi,
i want to ask about 2 strange audit messages. The messages are these:
Nov 5 14:14:24 asgard kernel: audit(1194268464.097:309): avc: denied
{ search } for pid=22933 comm="sh" name="src" dev=dm-0 ino=5244065
scontext=root:system_r:httpd_t:s0 tcontext=system_u:object_r:src_t:s0
tclass=dir
Nov 5 14:14:24 asgard kernel: audit(1194268464.124:310): avc: denied
{ getattr } for pid=22933 comm="sh" name="SPECS" dev=dm-0 ino=5865755
scontext=root:system_r:httpd_t:s0 tcontext=system_u:object_r:src_t:s0
tclass=dir
i don't know what is the reason sh to try to make something in /usr/src
and /usr/src/redhat/SPEC
we have not set some script that to have task to do something in these
directories. is it possible to be some hack attack ? also i see that
scontext is this: scontext=root:system_r:httpd_t:s0 is it possible to
understand where is the file that try to use "sh" ?
Also the audits:
Nov 5 12:03:07 casamerica kernel: audit(1194260587.185:40): avc:
denied { read write } for pid=26690 comm="listinfo" name="" dev=sockfs
ino=1414447 scontext=system_u:system_r:mailman_cgi_t:s0
tcontext=system_u:system_r:httpd_t:s0 tclass=unix_stream_socket
i have some similar messages related with mailmain, what is the best
that i can do to solve these messages?
Thanks in advanced!
16 years, 5 months