oops on reboot
by Arthur Dent
I don't reboot my machine very often (about once per month after a "yum
update") but each time I do I now get the following AVC:
=============8<=========================================================
SELinux is preventing /usr/bin/abrt-dump-oops from syslog_read access on
the system Unknown.
***** Plugin catchall (100. confidence) suggests
***************************
If you believe that abrt-dump-oops should be allowed syslog_read access
on the Unknown system by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep abrt-dump-oops /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
Additional Information:
Source Context system_u:system_r:abrt_helper_t:s0
Target Context system_u:system_r:kernel_t:s0
Target Objects Unknown [ system ]
Source abrt-dump-oops
Source Path /usr/bin/abrt-dump-oops
Port <Unknown>
Host example.com
Source RPM Packages abrt-addon-kerneloops-2.0.3-1.fc15
Target RPM Packages
Policy RPM selinux-policy-3.9.16-34.fc15
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name example.com
Platform Linux troodos.org.uk
2.6.38.8-35.fc15.i686.PAE #1
SMP Wed Jul 6 14:29:06 UTC 2011 i686 i686
Alert Count 3
First Seen Tue Jul 19 10:22:00 2011
Last Seen Thu Jul 21 11:34:47 2011
Local ID 9591fda1-fb84-4cd0-841e-650d306152f4
Raw Audit Messages
type=AVC msg=audit(1311244487.906:41): avc: denied { syslog_read } for
pid=1440 comm="abrt-dump-oops"
scontext=system_u:system_r:abrt_helper_t:s0
tcontext=system_u:system_r:kernel_t:s0 tclass=system
type=SYSCALL msg=audit(1311244487.906:41): arch=i386 syscall=syslog
success=no exit=EACCES a0=3 a1=90d70a8 a2=3fff a3=0 items=0 ppid=1
pid=1440 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=4294967295 comm=abrt-dump-oops
exe=/usr/bin/abrt-dump-oops subj=system_u:system_r:abrt_helper_t:s0
key=(null)
Hash: abrt-dump-oops,abrt_helper_t,kernel_t,system,syslog_read
audit2allow
#============= abrt_helper_t ==============
allow abrt_helper_t kernel_t:system syslog_read;
audit2allow -R
#============= abrt_helper_t ==============
allow abrt_helper_t kernel_t:system syslog_read;
=============8<=========================================================
Should I allow it?
Thanks in advance
Mark
12 years, 9 months
avc - f15
by Genes MailLists
I started getting this today:
(F15 + rawhide(3.0 kernel, procps)
ELinux is preventing /usr/libexec/abrt-hook-ccpp from using the
dac_override capability.
***** Plugin dac_override (91.4 confidence) suggests
***********************
If you want to help identify if domain needs this access or you have a
file with the wrong permissions on your system
Then turn on full auditing to get path information about the offending
file and generate the error again.
Do
Turn on full auditing
# auditctl -w /etc/shadow -p w
Try to recreate AVC. Then execute
# ausearch -m avc -ts recent
If you see PATH record check ownership/permissions on file, and fix it,
otherwise report as a bugzilla.
***** Plugin catchall (9.59 confidence) suggests
***************************
If you believe that abrt-hook-ccpp should have the dac_override
capability by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep abrt-hook-ccpp /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
Additional Information:
Source Context system_u:system_r:abrt_helper_t:s0
Target Context system_u:system_r:abrt_helper_t:s0
Target Objects Unknown [ capability ]
Source abrt-hook-ccpp
Source Path /usr/libexec/abrt-hook-ccpp
Port <Unknown>
Host lap3.prv.sapience.com
Source RPM Packages abrt-addon-ccpp-2.0.3-1.fc15
Target RPM Packages
Policy RPM selinux-policy-3.9.16-32.fc15
Selinux Enabled True
Policy Type targeted
Enforcing Mode Permissive
Host Name lap3.prv.sapience.com
Platform Linux lap3.prv.sapience.com
3.0-0.rc7.git0.1.fc16.x86_64 #1 SMP Tue Jul 12
12:57:40 UTC 2011 x86_64 x86_64
Alert Count 7
First Seen Sun 10 Jul 2011 12:38:18 PM EDT
Last Seen Wed 13 Jul 2011 07:28:22 AM EDT
Local ID 6ad9b5e6-ea7d-45ac-900f-7cac78bb5a0a
Raw Audit Messages
type=AVC msg=audit(1310556502.342:162): avc: denied { dac_override }
for pid=25068 comm="abrt-hook-ccpp" capability=1
scontext=system_u:system_r:abrt_helper_t:s0
tcontext=system_u:system_r:abrt_helper_t:s0 tclass=capability
type=SYSCALL msg=audit(1310556502.342:162): arch=x86_64 syscall=unlink
success=yes exit=0 a0=7fffc48cf140 a1=eed700 a2=fcfc a3=fffffffffffffff0
items=0 ppid=23033 pid=25068 auid=4294967295 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295
comm=abrt-hook-ccpp exe=/usr/libexec/abrt-hook-ccpp
subj=system_u:system_r:abrt_helper_t:s0 key=(null)
Hash: abrt-hook-ccpp,abrt_helper_t,abrt_helper_t,capability,dac_override
12 years, 9 months
proftpd with systemd on F-15
by Paul Howarth
I get various AVCs related to cgroup usage with systemd when logging in
to proftpd on F-15:
type=AVC msg=audit(1310388446.140:7884): avc: denied { read } for
pid=12071 comm="proftpd" name="cgroup" dev=proc ino=58466916
scontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023
tcontext=system_u:system_r:init_t:s0 tclass=file
type=AVC msg=audit(1310388446.140:7884): avc: denied { open } for
pid=12071 comm="proftpd" name="cgroup" dev=proc ino=58466916
scontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023
tcontext=system_u:system_r:init_t:s0 tclass=file
type=SYSCALL msg=audit(1310388446.140:7884): arch=c000003e syscall=2
success=yes exit=10 a0=2150480 a1=80000 a2=1b6 a3=9 items=0 ppid=11443
pid=12071 auid=1012 uid=0 gid=99 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=785 comm="proftpd" exe="/usr/sbin/proftpd"
subj=system_u:system_r:ftpd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1310388446.142:7885): avc: denied { getattr } for
pid=12071 comm="proftpd" path="/proc/1/cgroup" dev=proc ino=58466916
scontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023
tcontext=system_u:system_r:init_t:s0 tclass=file
type=SYSCALL msg=audit(1310388446.142:7885): arch=c000003e syscall=5
success=yes exit=0 a0=a a1=7fff0173a930 a2=7fff0173a930 a3=9 items=0
ppid=11443 pid=12071 auid=1012 uid=0 gid=99 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) ses=785 comm="proftpd" exe="/usr/sbin/proftpd"
subj=system_u:system_r:ftpd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1310388446.143:7886): avc: denied { write } for
pid=12071 comm="proftpd" name="phowarth" dev=cgroup ino=27218
scontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:cgroup_t:s0 tclass=dir
type=AVC msg=audit(1310388446.143:7886): avc: denied { add_name } for
pid=12071 comm="proftpd" name="785"
scontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:cgroup_t:s0 tclass=dir
type=AVC msg=audit(1310388446.143:7886): avc: denied { create } for
pid=12071 comm="proftpd" name="785"
scontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:cgroup_t:s0 tclass=dir
type=SYSCALL msg=audit(1310388446.143:7886): arch=c000003e syscall=83
success=yes exit=0 a0=2150370 a1=1ed a2=0 a3=776f68702f726573 items=0
ppid=11443 pid=12071 auid=1012 uid=0 gid=99 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) ses=785 comm="proftpd" exe="/usr/sbin/proftpd"
subj=system_u:system_r:ftpd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1310388446.143:7887): avc: denied { write } for
pid=12071 comm="proftpd" name="tasks" dev=cgroup ino=58575429
scontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:cgroup_t:s0 tclass=file
type=AVC msg=audit(1310388446.143:7887): avc: denied { open } for
pid=12071 comm="proftpd" name="tasks" dev=cgroup ino=58575429
scontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:cgroup_t:s0 tclass=file
type=SYSCALL msg=audit(1310388446.143:7887): arch=c000003e syscall=2
success=yes exit=11 a0=2150370 a1=80241 a2=1b6 a3=9 items=0 ppid=11443
pid=12071 auid=1012 uid=0 gid=99 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=785 comm="proftpd" exe="/usr/sbin/proftpd"
subj=system_u:system_r:ftpd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1310388446.143:7888): avc: denied { getattr } for
pid=12071 comm="proftpd"
path="/sys/fs/cgroup/systemd/user/phowarth/785/tasks" dev=cgroup
ino=58575429 scontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:cgroup_t:s0 tclass=file
type=SYSCALL msg=audit(1310388446.143:7888): arch=c000003e syscall=5
success=yes exit=0 a0=b a1=7fff0173b100 a2=7fff0173b100 a3=9 items=0
ppid=11443 pid=12071 auid=1012 uid=0 gid=99 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) ses=785 comm="proftpd" exe="/usr/sbin/proftpd"
subj=system_u:system_r:ftpd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1310388446.150:7889): avc: denied { setattr } for
pid=12071 comm="proftpd" name="tasks" dev=cgroup ino=58575429
scontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:cgroup_t:s0 tclass=file
type=SYSCALL msg=audit(1310388446.150:7889): arch=c000003e syscall=90
success=yes exit=0 a0=2150370 a1=1a4 a2=3f4 a3=6f68702f72657375 items=0
ppid=11443 pid=12071 auid=1012 uid=0 gid=99 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) ses=785 comm="proftpd" exe="/usr/sbin/proftpd"
subj=system_u:system_r:ftpd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1310388446.150:7890): avc: denied { setattr } for
pid=12071 comm="proftpd" name="785" dev=cgroup ino=58575428
scontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:cgroup_t:s0 tclass=dir
type=SYSCALL msg=audit(1310388446.150:7890): arch=c000003e syscall=90
success=yes exit=0 a0=2150370 a1=1ed a2=3f4 a3=6f68702f72657375 items=0
ppid=11443 pid=12071 auid=1012 uid=0 gid=99 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) ses=785 comm="proftpd" exe="/usr/sbin/proftpd"
subj=system_u:system_r:ftpd_t:s0-s0:c0.c1023 key=(null)
/var/log/messages includes:
Jul 11 13:47:21 roary proftpd[12071]: 10.9.2.1 (10.9.2.1[10.9.2.1]) -
FTP session opened.
Jul 11 12:47:26 roary proftpd[12071]: 10.9.2.1 (10.9.2.1[10.9.2.1]) -
Preparing to chroot to directory '/nis-home/phowarth'
Jul 11 13:47:29 roary kernel: [2670919.902960] proftpd[12071]:
pam_systemd(proftpd:session): Failed to lock runtime directory:
Permission denied
Jul 11 13:47:29 roary kernel: [2670919.902978] proftpd[12071]:
pam_unix(proftpd:session): session closed for user phowarth
Jul 11 13:47:29 roary kernel: [2670919.904278] proftpd[12071]: 10.9.2.1
(10.9.2.1[10.9.2.1]) - FTP session closed.
audit2allow -R suggests:
fs_manage_cgroup_dirs(ftpd_t)
fs_manage_cgroup_files(ftpd_t)
init_read_state(ftpd_t)
proftpd does appear to work despite these messages, so I'm wondering if
it would be better to dontaudit these rather than allow them?
Paul.
12 years, 9 months
named issue
by Genes MailLists
I'm getting these - is it something specific to my setup?
I'm up to date and policy rpm's are:
selinux-policy.noarch 3.9.16-32.fc15 @updates
selinux-policy-targeted.noarch 3.9.16-32.fc15 @updates
thanks for any advice.
gene
----------------------
SELinux is preventing /usr/sbin/named from add_name access on the
directory named.pid.
***** Plugin catchall_boolean (89.3 confidence) suggests
*******************
If you want to allow BIND to write the master zone files. Generally this
is used for dynamic DNS or zone transfers.
Then you must tell SELinux about this by enabling the
'named_write_master_zones' boolean.
Do
setsebool -P named_write_master_zones 1
***** Plugin catchall (11.6 confidence) suggests
***************************
If you believe that named should be allowed add_name access on the
named.pid directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep named /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
12 years, 9 months
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, 9 months
A question about roles
by mark
Feel free to point me to a link that discusses this, but how *does*
selinux decide on roles when I'm using restorecon? Does it use the context
of the directory above it, or that it's in, or is there something else?
mark
12 years, 9 months
Re: tftp from home dir running under xinetd
by Marcos Ortiz Valmaseda
For that reason, you have to see the avc denials; where you can check which is the process and system calls that are been denied (xinetd or tftpd)
Which is the SELinux policy version in your machine?
Regards
----- Mensaje original -----
De: "Gene Smith" <gds(a)chartertn.net>
Para: users(a)lists.fedoraproject.org
CC: selinux(a)lists.fedoraproject.org
Enviados: Lunes, 4 de Julio 2011 19:49:37 GMT +01:00 Amsterdam / Berlín / Berna / Roma / Estocolmo / Viena
Asunto: Re: tftp from home dir running under xinetd
Marcos Ortiz Valmaseda wrote, On 07/04/2011 01:44 PM:
> We need the /varlog/messages or the /var/log/audit/audit.log to see what happens on the system.
>
> CC to selinux list too
>
> Try to do this:
> 1- setenforce 0 to change to "permissive" mode
>
> 2- stop tftpd daemon:
> # service tftpd stop
Thanks, I will try all this later when I have more time. However, does
it matter that I don't have a running tftpd but only xinetd that
activates tftdp on demand?
>
> 3- unload any rules that silently deny access
> # semodule -DB
>
> 4- check the time:
> # date
>
> 5- start the tftpd service:
> # service tftpd start
>
> 6- Then, collect all the Access Vector Cache (ACV) denials that occured since you noted the system time. For example
>
> # ausearch -m avc -ts 15:00
>
> 7- Filter the log and try to generate a policy module using audit2allow:
> # grep "tftpd" /var/log/audit/audit.log | audit2allow -M tftpd
>
> 8- Check the tftpd.{te,.fc} files, and if you have enough with it, you can install the policy module:
>
> # semodule -i tftpd.pp
>
> 9- Then, check if the avc denials persists
>
> Regards
>
>
> ----- Mensaje original -----
> De: "Gene Smith"<gds(a)chartertn.net>
> Para: users(a)lists.fedoraproject.org
> Enviados: Lunes, 4 de Julio 2011 18:11:51 GMT +01:00 Amsterdam / Berlín / Berna / Roma / Estocolmo / Viena
> Asunto: Re: tftp from home dir running under xinetd
>
> Marcos Ortiz wrote, On 07/04/2011 02:02 AM:
>> Can you show here the error in the log?
>> Do you have SELinux enabled in enforcing mode?
>> Try to do this: getsetbool -a | grep tftpd to see all boolean related to
>> this service.
>>
>> Regards
>
> $ getsebool -a | grep tftp
> tftp_anon_write --> off
>
> I have set this bool to "on" via the selinux gui and it made no
> difference. (Also, I am not not trying to write via tftp, just read.)
>
> This is the error I see running with in full enforcing mode and it
> occurs each time the remote host (a bdi2000 jtag emulator) attempts to
> read its configuration file using tftp from the fedora box.
>
> Jul 4 00:36:33 wally xinetd[6013]: START: tftp pid=6706 from=192.168.1.21
> Jul 4 00:36:33 wally in.tftpd[6706]: /home/gene/my_dir: Permission denied
> Jul 4 00:36:33 wally xinetd[6013]: EXIT: tftp status=66 pid=6706
> duration=0(sec)
>
> When I change just the tftpd process to "permissive" using the selinux
> gui it fixes the problem.
>
> Note: If I put the files read by the emulator in the "standard"
> location, /var/lib/tftpd, it works OK in full enforcing mode.
>
> -gene
>
>>
>> On 07/04/2011 12:50 AM, Gene Smith wrote:
>>> I can manually run a tftp server that allows access to files in a
>>> directory under ~ with no problem. But when I try to run the server
>>> under xinetd using the /etc/xinetd.d/tftp configuration file a
>>> "permission denied" error shows up in /var/log/message with no
>>> indication it is selinux related. But if I make selinux permissive for
>>> tftpd it then works.
>>>
>>> Is there a quick way to configure selinux to allow this type of tftp
>>> access (just read-only) w/o resorting to a "permissive" setting?
>>>
>>> Thanks,
>>> -gene
>>>
>>
>> --
>> Marcos Luís Ortíz Valmaseda
>> Software Engineer (UCI)
>> http://marcosluis2186.posterous.com
>> http://twitter.com/marcosluis2186
>>
>
>
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
--
Marcos Luís Ortíz Valmaseda
Software Engineer (Large-Scaled Distributed Systems)
http://marcosluis2186.posterous.com
12 years, 9 months
Re: tftp from home dir running under xinetd
by Marcos Ortiz Valmaseda
We need the /varlog/messages or the /var/log/audit/audit.log to see what happens on the system.
CC to selinux list too
Try to do this:
1- setenforce 0 to change to "permissive" mode
2- stop tftpd daemon:
# service tftpd stop
3- unload any rules that silently deny access
# semodule -DB
4- check the time:
# date
5- start the tftpd service:
# service tftpd start
6- Then, collect all the Access Vector Cache (ACV) denials that occured since you noted the system time. For example
# ausearch -m avc -ts 15:00
7- Filter the log and try to generate a policy module using audit2allow:
# grep "tftpd" /var/log/audit/audit.log | audit2allow -M tftpd
8- Check the tftpd.{te,.fc} files, and if you have enough with it, you can install the policy module:
# semodule -i tftpd.pp
9- Then, check if the avc denials persists
Regards
----- Mensaje original -----
De: "Gene Smith" <gds(a)chartertn.net>
Para: users(a)lists.fedoraproject.org
Enviados: Lunes, 4 de Julio 2011 18:11:51 GMT +01:00 Amsterdam / Berlín / Berna / Roma / Estocolmo / Viena
Asunto: Re: tftp from home dir running under xinetd
Marcos Ortiz wrote, On 07/04/2011 02:02 AM:
> Can you show here the error in the log?
> Do you have SELinux enabled in enforcing mode?
> Try to do this: getsetbool -a | grep tftpd to see all boolean related to
> this service.
>
> Regards
$ getsebool -a | grep tftp
tftp_anon_write --> off
I have set this bool to "on" via the selinux gui and it made no
difference. (Also, I am not not trying to write via tftp, just read.)
This is the error I see running with in full enforcing mode and it
occurs each time the remote host (a bdi2000 jtag emulator) attempts to
read its configuration file using tftp from the fedora box.
Jul 4 00:36:33 wally xinetd[6013]: START: tftp pid=6706 from=192.168.1.21
Jul 4 00:36:33 wally in.tftpd[6706]: /home/gene/my_dir: Permission denied
Jul 4 00:36:33 wally xinetd[6013]: EXIT: tftp status=66 pid=6706
duration=0(sec)
When I change just the tftpd process to "permissive" using the selinux
gui it fixes the problem.
Note: If I put the files read by the emulator in the "standard"
location, /var/lib/tftpd, it works OK in full enforcing mode.
-gene
>
> On 07/04/2011 12:50 AM, Gene Smith wrote:
>> I can manually run a tftp server that allows access to files in a
>> directory under ~ with no problem. But when I try to run the server
>> under xinetd using the /etc/xinetd.d/tftp configuration file a
>> "permission denied" error shows up in /var/log/message with no
>> indication it is selinux related. But if I make selinux permissive for
>> tftpd it then works.
>>
>> Is there a quick way to configure selinux to allow this type of tftp
>> access (just read-only) w/o resorting to a "permissive" setting?
>>
>> Thanks,
>> -gene
>>
>
> --
> Marcos Luís Ortíz Valmaseda
> Software Engineer (UCI)
> http://marcosluis2186.posterous.com
> http://twitter.com/marcosluis2186
>
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
--
Marcos Luís Ortíz Valmaseda
Software Engineer (Large-Scaled Distributed Systems)
http://marcosluis2186.posterous.com
12 years, 9 months
