A few permission problems

[Nicklas Norling]

Hi.

I've got a system updated from old redhat releases to FC2-3 and now 4.
I've just downloaded selinux-policy-targeted and have been able to fix 
most of
my problems with setsebool etc. while in permissive mode. However a few more
difficult issues still intrigues me and I'd love it if someone would 
offer some help.

First:
[root@spock ~]# audit2allow -i /var/log/messages -l
allow dovecot_auth_t selinux_config_t:file { getattr read };
allow httpd_sys_script_t var_t:dir getattr;
allow named_t unconfined_t:fifo_file read;
allow smbd_t selinux_config_t:dir search;
allow smbd_t selinux_config_t:file { getattr read };
allow webalizer_t home_root_t:dir search;
allow webalizer_t user_home_dir_t:dir search;


The dovecot-auth problem seems to occur with every new connection to 
dovecot:

Jul 16 14:00:16 spock kernel: audit(1121515216.305:122): avc:  denied  { 
read } for  pid=21686 comm="dovecot-auth" name="config" dev=hda3 
ino=394549 scontext=root:system_r:dovecot_auth_t 
tcontext=system_u:object_r:selinux_config_t tclass=file
Jul 16 14:00:16 spock kernel: audit(1121515216.305:123): avc:  denied  { 
getattr } for  pid=21686 comm="dovecot-auth" name="config" dev=hda3 
ino=394549 scontext=root:system_r:dovecot_auth_t 
tcontext=system_u:object_r:selinux_config_t tclass=file


The httpd problem appears to be python related. Not sure which of my web 
applications is triggering it
(if any). Maybe MoinMoin Wiki but I can't seem to trigger it myself, 
maybe a search spider is triggering it.

Jul 16 02:00:54 spock kernel: audit(1121472054.557:119): avc:  denied  { 
getattr } for  pid=20378 comm="python" name="var" dev=hda3 ino=163841

scontext=root:system_r:httpd_sys_script_t 
tcontext=system_u:object_r:var_t tclass=dir


named is denied some fun?

Jul 14 15:39:10 spock named[1771]: exiting
Jul 14 15:39:12 spock kernel: audit(1121348352.535:98): avc:  denied  { 
read } for  pid=16108 comm="named-checkconf" name
="[196624]" dev=pipefs ino=196624 scontext=root:system_r:named_t 
tcontext=root:system_r:unconfined_t tclass=fifo_file
Jul 14 15:39:12 spock named[16110]: starting BIND 9.3.1 -u named


Samba appears to wan't to read in the selinux config file? Every access 
to a home directory triggers this despite the correct sebool is set.

Jul 15 02:43:18 spock kernel: audit(1121388198.077:104): avc:  denied  { 
search } for  pid=17122 comm="smbd" name="selinu
x" dev=hda3 ino=394114 scontext=system_u:system_r:smbd_t 
tcontext=system_u:object_r:selinux_config_t tclass=dir
Jul 15 02:43:18 spock kernel: audit(1121388198.077:105): avc:  denied  { 
read } for  pid=17122 comm="smbd" name="config"
dev=hda3 ino=394549 scontext=system_u:system_r:smbd_t 
tcontext=system_u:object_r:selinux_config_t tclass=file
Jul 15 02:43:18 spock kernel: audit(1121388198.078:106): avc:  denied  { 
getattr } for  pid=17122 comm="smbd" name="config" dev=hda3 ino=394549

scontext=system_u:system_r:smbd_t 
tcontext=system_u:object_r:selinux_config_t tclass=file


webalizer is being asked to put it's resulting webpages into a local 
users web directory in support of per user usage stat. The users 
webfolder has the correct objects set for httpd security.

Jul 11 04:02:17 spock kernel: audit(1121047337.762:57): avc:  denied  { 
search } for  pid=3409 comm="webalizer" name="home" dev=hda3
ino=819203 
scontext=system_u:system_r:webalizer_t 
tcontext=system_u:object_r:home_root_t tclass=dir
Jul 11 04:02:17 spock kernel: audit(1121047337.762:58): avc:  denied  { 
search } for  pid=3409 comm="webalizer" name="joakim" dev=hda3 
ino=458781 scontext=system_u:system_r:webalizer_t 
tcontext=user_u:object_r:user_home_dir_t tclass=dir


In addition to this I have a shared folder with 'public' material, files 
that I offer to for download/upload. This folder is shared to my users 
with ftp as well as samba. Is this even possible to do with selinux?

Jul 16 15:24:31 spock kernel: audit(1121520271.993:127): avc:  denied  { 
search } for  pid=21818 comm="smbd" name="/" dev=hdc1 ino=2 
scontext=system_u:system_r:smbd_t tcontext=system_u:object_r:ftpd_anon_t 
tclass=dir
Jul 16 15:24:32 spock kernel: audit(1121520272.060:128): avc:  denied  { 
getattr } for  pid=21818 comm="smbd" name="pub" dev=hdc1 ino=32769 
scontext=system_u:system_r:smbd_t tcontext=system_u:object_r:ftpd_anon_t 
tclass=dir
Jul 16 15:24:32 spock kernel: audit(1121520272.156:129): avc:  denied  { 
read } for  pid=21818 comm="smbd" name="pub" dev=hdc1 ino=32769 
scontext=system_u:system_r:smbd_t tcontext=system_u:object_r:ftpd_anon_t 
tclass=dir

audit2allow suggests:
allow smbd_t ftpd_anon_t:dir { getattr read search };

Greatful for any tips, hoping to enforce soon!
/Nicke

[Daniel J Walsh]

Nicklas Norling wrote:

>  Hi.
>
>  I've got a system updated from old redhat releases to FC2-3 and now 4.
>  I've just downloaded selinux-policy-targeted and have been able to fix 
>  most of
>  my problems with setsebool etc. while in permissive mode. However a 
>  few more
>  difficult issues still intrigues me and I'd love it if someone would 
>  offer some help.
>
>  First:
>  [root@spock ~]# audit2allow -i /var/log/messages -l
>  allow dovecot_auth_t selinux_config_t:file { getattr read };
>  allow httpd_sys_script_t var_t:dir getattr;
>  allow named_t unconfined_t:fifo_file read;
>  allow smbd_t selinux_config_t:dir search;
>  allow smbd_t selinux_config_t:file { getattr read };
>  allow webalizer_t home_root_t:dir search;
>  allow webalizer_t user_home_dir_t:dir search;
>
>
>  The dovecot-auth problem seems to occur with every new connection to 
>  dovecot:
>
>  Jul 16 14:00:16 spock kernel: audit(1121515216.305:122): avc:  denied  
>  { read } for  pid=21686 comm="dovecot-auth" name="config" dev=hda3 
>  ino=394549 scontext=root:system_r:dovecot_auth_t 
>  tcontext=system_u:object_r:selinux_config_t tclass=file
>  Jul 16 14:00:16 spock kernel: audit(1121515216.305:123): avc:  denied  
>  { getattr } for  pid=21686 comm="dovecot-auth" name="config" dev=hda3
>
>  ino=394549 scontext=root:system_r:dovecot_auth_t 
>  tcontext=system_u:object_r:selinux_config_t tclass=file
>  
The would be suppressed by a dontaudit rule if you were running in 
enforcing.  Always attempt to reproduce AVC messages in enforcing mode, 
since these are the ones we will fix.  Permissive mode should only be 
run temporarily to get around a problem.  Targeted policy gives a lot of 
"False" avc messages.

>  The httpd problem appears to be python related. Not sure which of my 
>  web applications is triggering it
>  (if any). Maybe MoinMoin Wiki but I can't seem to trigger it myself, 
>  maybe a search spider is triggering it.
>
>  Jul 16 02:00:54 spock kernel: audit(1121472054.557:119): avc:  denied  
>  { getattr } for  pid=20378 comm="python" name="var" dev=hda3 
>  ino=163841 scontext=root:system_r:httpd_sys_script_t 
>  tcontext=system_u:object_r:var_t tclass=dir
>  
Yes the question would be which file/dir is it trying to  read under /var

>  named is denied some fun?
>
>  Jul 14 15:39:10 spock named[1771]: exiting
>  Jul 14 15:39:12 spock kernel: audit(1121348352.535:98): avc:  denied  
>  { read } for  pid=16108 comm="named-checkconf" name
>  ="[196624]" dev=pipefs ino=196624 scontext=root:system_r:named_t 
>  tcontext=root:system_r:unconfined_t tclass=fifo_file
>  Jul 14 15:39:12 spock named[16110]: starting BIND 9.3.1 -u named
>  
Is this only happening on a yum update/RPM install?

>  Samba appears to wan't to read in the selinux config file? Every 
>  access to a home directory triggers this despite the correct sebool is 
>  set.
>
>  Jul 15 02:43:18 spock kernel: audit(1121388198.077:104): avc:  denied  
>  { search } for  pid=17122 comm="smbd" name="selinu
>  x" dev=hda3 ino=394114 scontext=system_u:system_r:smbd_t 
>  tcontext=system_u:object_r:selinux_config_t tclass=dir
>  Jul 15 02:43:18 spock kernel: audit(1121388198.077:105): avc:  denied  
>  { read } for  pid=17122 comm="smbd" name="config"
>  dev=hda3 ino=394549 scontext=system_u:system_r:smbd_t 
>  tcontext=system_u:object_r:selinux_config_t tclass=file
>  Jul 15 02:43:18 spock kernel: audit(1121388198.078:106): avc:  denied  
>  { getattr } for  pid=17122 comm="smbd" name="config" dev=hda3 
>  ino=394549 scontext=system_u:system_r:smbd_t 
>  tcontext=system_u:object_r:selinux_config_t tclass=file
>  
These should be dontaudited.  Again run under enforcing mode.

>  webalizer is being asked to put it's resulting webpages into a local 
>  users web directory in support of per user usage stat. The users 
>  webfolder has the correct objects set for httpd security.
>
>  Jul 11 04:02:17 spock kernel: audit(1121047337.762:57): avc:  denied  
>  { search } for  pid=3409 comm="webalizer" name="home" dev=hda3 
>  ino=819203 scontext=system_u:system_r:webalizer_t 
>  tcontext=system_u:object_r:home_root_t tclass=dir
>  Jul 11 04:02:17 spock kernel: audit(1121047337.762:58): avc:  denied  
>  { search } for  pid=3409 comm="webalizer" name="joakim" dev=hda3 
>  ino=458781 scontext=system_u:system_r:webalizer_t 
>  tcontext=user_u:object_r:user_home_dir_t tclass=dir
>  
You will need to write your own policy for this.    Alternatively you 
could create a directory under /var/www with the
label httpd_sys_content_t and allow webalizer to write their and allow 
users to read it.

>  tclass=file
>  In addition to this I have a shared folder with 'public' material, 
>  files that I offer to for download/upload. This folder is shared to my 
>  users with ftp as well as samba. Is this even possible to do with 
>  selinux?
>
>  Jul 16 15:24:31 spock kernel: audit(1121520271.993:127): avc:  denied  
>  { search } for  pid=21818 comm="smbd" name="/" dev=hdc1 ino=2 
>  scontext=system_u:system_r:smbd_t 
>  tcontext=system_u:object_r:ftpd_anon_t tclass=dir
>  Jul 16 15:24:32 spock kernel: audit(1121520272.060:128): avc:  denied  
>  { getattr } for  pid=21818 comm="smbd" name="pub" dev=hdc1 ino=32769
>
>  scontext=system_u:system_r:smbd_t 
>  tcontext=system_u:object_r:ftpd_anon_t tclass=dir
>  Jul 16 15:24:32 spock kernel: audit(1121520272.156:129): avc:  denied  
>  { read } for  pid=21818 comm="smbd" name="pub" dev=hdc1 ino=32769 
>  scontext=system_u:system_r:smbd_t 
>  tcontext=system_u:object_r:ftpd_anon_t tclass=dir
>
>  audit2allow suggests:
>  allow smbd_t ftpd_anon_t:dir { getattr read search };
>  
You could add this rule to your local.te file.  We have discussed this 
in the past and maybe a boolean allowing all apps to read "shared data" 
would work.

>  Greatful for any tips, hoping to enforce soon!
>  /Nicke
>
>  -- 
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  http://www.redhat.com/mailman/listinfo/fedora-selinux-list 


--

[Nicklas Norling]

Daniel J Walsh wrote:

>  Nicklas Norling wrote:
>
> > Hi.
> >
> > I've got a system updated from old redhat releases to FC2-3 and now 4.
> > I've just downloaded selinux-policy-targeted and have been able to 
> > fix most of
> > my problems with setsebool etc. while in permissive mode. However a 
> > few more
> > difficult issues still intrigues me and I'd love it if someone would 
> > offer some help.
> >
> > <snip>
>
> >
> > The httpd problem appears to be python related. Not sure which of my 
> > web applications is triggering it
> > (if any). Maybe MoinMoin Wiki but I can't seem to trigger it myself, 
> > maybe a search spider is triggering it.
> >
> > Jul 16 02:00:54 spock kernel: audit(1121472054.557:119): avc:  
> > denied  { getattr } for  pid=20378 comm="python" name="var"
> dev=hda3 
> > ino=163841 scontext=root:system_r:httpd_sys_script_t 
> > tcontext=system_u:object_r:var_t tclass=dir
> >
>  Yes the question would be which file/dir is it trying to  read under /var
>  
Indeed, I shall keep my eyes open and report back if I can figure it out.

> >
> > named is denied some fun?
> >
> > Jul 14 15:39:10 spock named[1771]: exiting
> > Jul 14 15:39:12 spock kernel: audit(1121348352.535:98): avc:  denied  
> > { read } for  pid=16108 comm="named-checkconf" name
> > ="[196624]" dev=pipefs ino=196624 scontext=root:system_r:named_t 
> > tcontext=root:system_r:unconfined_t tclass=fifo_file
> > Jul 14 15:39:12 spock named[16110]: starting BIND 9.3.1 -u named
> >
>  Is this only happening on a yum update/RPM install?
>  
Yes it does. I read between the line(s) that is expected. Still looks 
worrying to a noob like myself.

>  <snip>
>
> >
> > webalizer is being asked to put it's resulting webpages into a local 
> > users web directory in support of per user usage stat. The users 
> > webfolder has the correct objects set for httpd security.
> >
> > Jul 11 04:02:17 spock kernel: audit(1121047337.762:57): avc:  denied  
> > { search } for  pid=3409 comm="webalizer" name="home" dev=hda3 
> > ino=819203 scontext=system_u:system_r:webalizer_t 
> > tcontext=system_u:object_r:home_root_t tclass=dir
> > Jul 11 04:02:17 spock kernel: audit(1121047337.762:58): avc:  denied  
> > { search } for  pid=3409 comm="webalizer" name="joakim" dev=hda3
>
> > ino=458781 scontext=system_u:system_r:webalizer_t 
> > tcontext=user_u:object_r:user_home_dir_t tclass=dir
> >
>  You will need to write your own policy for this.    Alternatively you 
>  could create a directory under /var/www with the
>  label httpd_sys_content_t and allow webalizer to write their and allow 
>  users to read it.
>  
Hmm, ok. Maybe webalizer should have a boolean for accessing http home 
dir provided httpd_enable_homedirs=1?
Or maybe my way of doing this is so odd it's worth the trouble.

> > tclass=file
> > In addition to this I have a shared folder with 'public' material, 
> > files that I offer to for download/upload. This folder is shared to 
> > my users with ftp as well as samba. Is this even possible to do with 
> > selinux?
> >
> > Jul 16 15:24:31 spock kernel: audit(1121520271.993:127): avc:  
> > denied  { search } for  pid=21818 comm="smbd" name="/" dev=hdc1
> ino=2 
> > scontext=system_u:system_r:smbd_t 
> > tcontext=system_u:object_r:ftpd_anon_t tclass=dir
> > Jul 16 15:24:32 spock kernel: audit(1121520272.060:128): avc:  
> > denied  { getattr } for  pid=21818 comm="smbd" name="pub"
> dev=hdc1 
> > ino=32769 scontext=system_u:system_r:smbd_t 
> > tcontext=system_u:object_r:ftpd_anon_t tclass=dir
> > Jul 16 15:24:32 spock kernel: audit(1121520272.156:129): avc:  
> > denied  { read } for  pid=21818 comm="smbd" name="pub" dev=hdc1 
> > ino=32769 scontext=system_u:system_r:smbd_t 
> > tcontext=system_u:object_r:ftpd_anon_t tclass=dir
> >
> > audit2allow suggests:
> > allow smbd_t ftpd_anon_t:dir { getattr read search };
> >
>  You could add this rule to your local.te file.  We have discussed this 
>  in the past and maybe a boolean allowing all apps to read "shared 
>  data" would work.
>  
Ok, I think adding the rule is the way to go for me. Some more learning 
to do.
I would encourage a boolean for shared data location. I think labeling a 
folder and it's subcontent with a specific label and then have different 
services be able to use it might be a start. That way I could disallow 
smb the rights but allow ftpd and httpd (as an example). I think that 
would be a great improvment from my point of view.

Since 01:22:00 this day my server is in enforce mode. The only thing 
I've found so far is sendmail being denied access to urandom and random. 
I have sendmail setup with SMTP AUTH as well as certs for performing 
STARTTLS with any TLS-able connecting MTA.

/var/log/messages
Jul 19 08:09:38 spock kernel: audit(1121753378.808:188): avc:  denied  { 
getattr } for  pid=20520 comm="sendmail" name="urandom" dev=tmpfs 
ino=846 
scontext=root:system_r:system_mail_ttcontext=system_u:object_r:urandom_device_t 
tclass=chr_file
Jul 19 08:09:38 spock kernel: audit(1121753378.808:189): avc:  denied  { 
getattr } for  pid=20520 comm="sendmail" name="random" dev=tmpfs
ino=844 
scontext=root:system_r:system_mail_ttcontext=system_u:object_r:random_device_t 
tclass=chr_file

/var/log/maillog
Jul 19 08:09:38 spock sendmail[20520]: j6J69cMx020520: from=<edited>, 
size=874, class=0, nrcpts=1, 
msgid=&lt;bd1035dcc05d7b2d6a16b046ae4bdd04(a)www.exinor.net&gt;, 
bodytype=8BITMIME, relay=apache@localhost
Jul 19 08:09:38 spock sendmail[20520]: j6J69cMx020520: STARTTLS=client, 
error: connect failed=-1, SSL_error=5, timedout=0, errno=2
Jul 19 08:09:38 spock sendmail[20520]: ruleset=tls_server, 
arg1=SOFTWARE, relay=[127.0.0.1], reject=403 4.7.0TLS handshake.
Jul 19 08:09:38 spock sendmail[20520]: j6J69cMx020520: to=<edited>, 
ctladdr=<edited> (48/48), delay=00:00:00, xdelay=00:00:00, mailer=relay, 
pri=30874, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: 403 
4.7.0 TLS handshake.
Jul 19 08:09:38 spock sendmail[20521]: STARTTLS=server, error: accept 
failed=0, SSL_error=5, timedout=0,errno=0
Jul 19 08:09:38 spock sendmail[20521]: j6J69cai020521: localhost 
[127.0.0.1] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

audit2allow -d -l
allow system_mail_t random_device_t:chr_file getattr;
allow system_mail_t urandom_device_t:chr_file getattr;

Policy rpm installed: selinux-policy-targeted-1.25.1-9.noarch.rpm

Apart from this DoS on sendmail my system appears to be working as expected.

Personally I'd love to see permissive mode similar to enforcing when it 
come's to avc's. I don't like the idea of turning on enforcing to see 
things not work and then turn it off. Much rather would I use permissive 
mode to investigate what will go wrong so I can fix problems before I 
DoS myself.

Thanks a lot for all your help Daniel, I sure appretiate it!
/Nicke

[Nicklas Norling]

Nicklas Norling wrote:

>  <snip>
>  Since 01:22:00 this day my server is in enforce mode. The only thing 
>  I've found so far is sendmail being denied access to urandom and 
>  random. I have sendmail setup with SMTP AUTH as well as certs for 
>  performing STARTTLS with any TLS-able connecting MTA.
>
>  /var/log/messages
>  Jul 19 08:09:38 spock kernel: audit(1121753378.808:188): avc:  denied  
>  { getattr } for  pid=20520 comm="sendmail" name="urandom" dev=tmpfs 
>  ino=846 
>  scontext=root:system_r:system_mail_ttcontext=system_u:object_r:urandom_device_t 
>  tclass=chr_file
>  Jul 19 08:09:38 spock kernel: audit(1121753378.808:189): avc:  denied  
>  { getattr } for  pid=20520 comm="sendmail" name="random" dev=tmpfs 
>  ino=844 
>  scontext=root:system_r:system_mail_ttcontext=system_u:object_r:random_device_t 
>  tclass=chr_file
>
>  /var/log/maillog
>  Jul 19 08:09:38 spock sendmail[20520]: j6J69cMx020520: from=<edited>, 
>  size=874, class=0, nrcpts=1, 
>  msgid=&lt;bd1035dcc05d7b2d6a16b046ae4bdd04(a)www.exinor.net&gt;, 
>  bodytype=8BITMIME, relay=apache@localhost
>  Jul 19 08:09:38 spock sendmail[20520]: j6J69cMx020520: 
>  STARTTLS=client, error: connect failed=-1, SSL_error=5, timedout=0, 
>  errno=2
>  Jul 19 08:09:38 spock sendmail[20520]: ruleset=tls_server, 
>  arg1=SOFTWARE, relay=[127.0.0.1], reject=403 4.7.0TLS handshake.
>  Jul 19 08:09:38 spock sendmail[20520]: j6J69cMx020520: to=<edited>, 
>  ctladdr=<edited> (48/48), delay=00:00:00, xdelay=00:00:00, 
>  mailer=relay, pri=30874, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, 
>  stat=Deferred: 403 4.7.0 TLS handshake.
>  Jul 19 08:09:38 spock sendmail[20521]: STARTTLS=server, error: accept 
>  failed=0, SSL_error=5, timedout=0,errno=0
>  Jul 19 08:09:38 spock sendmail[20521]: j6J69cai020521: localhost 
>  [127.0.0.1] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>
>  audit2allow -d -l
>  allow system_mail_t random_device_t:chr_file getattr;
>  allow system_mail_t urandom_device_t:chr_file getattr;
>
>  Policy rpm installed: selinux-policy-targeted-1.25.1-9.noarch.rpm
>  
<snip>

I've installed selinux-policy-targeted-sources-1.25.1-9.noarch.rpm, edited
/etc/selinux/targeted/src/policy/domains/misc/local.te to contain:

allow system_mail_t random_device_t:chr_file getattr;
allow system_mail_t urandom_device_t:chr_file getattr;

Then did a 'make reload' in /etc/selinux/targeted/src/policy as per 
instructions I found on the net.
This made the sendmail TLS errors go away, however, trying smtp auth 
saslauthd complains instead:

Jul 19 14:14:19 spock saslauthd[22499]: do_auth         : auth failure: 
[user=<edited>] [service=smtp] [realm=] [mech=shadow] [reason=Unknown]
Jul 19 14:14:19 spock saslauthd[22500]: do_auth         : auth failure: 
[user=<edited>] [service=smtp] [realm=] [mech=shadow] [reason=Unknown]

'setenforce 0' makes it all work. No avc's in the logs during enforcing 
mode.

I guess my pathetic attempts at creating local rules failed misserably :(
I'm in way over my head here I think... Any pointers?
/Nicke

[Daniel J Walsh]

Nicklas Norling wrote:

>  Nicklas Norling wrote:
>
> > <snip>
> > Since 01:22:00 this day my server is in enforce mode. The only thing 
> > I've found so far is sendmail being denied access to urandom and 
> > random. I have sendmail setup with SMTP AUTH as well as certs for 
> > performing STARTTLS with any TLS-able connecting MTA.
> >
> > /var/log/messages
> > Jul 19 08:09:38 spock kernel: audit(1121753378.808:188): avc:  
> > denied  { getattr } for  pid=20520 comm="sendmail" name="urandom"
>
> > dev=tmpfs ino=846 
> > scontext=root:system_r:system_mail_ttcontext=system_u:object_r:urandom_device_t 
> > tclass=chr_file
> > Jul 19 08:09:38 spock kernel: audit(1121753378.808:189): avc:  
> > denied  { getattr } for  pid=20520 comm="sendmail" name="random"
>
> > dev=tmpfs ino=844 
> > scontext=root:system_r:system_mail_ttcontext=system_u:object_r:random_device_t 
> > tclass=chr_file
> >
> > /var/log/maillog
> > Jul 19 08:09:38 spock sendmail[20520]: j6J69cMx020520: from=<edited>, 
> > size=874, class=0, nrcpts=1, 
> > msgid=&lt;bd1035dcc05d7b2d6a16b046ae4bdd04(a)www.exinor.net&gt;, 
> > bodytype=8BITMIME, relay=apache@localhost
> > Jul 19 08:09:38 spock sendmail[20520]: j6J69cMx020520: 
> > STARTTLS=client, error: connect failed=-1, SSL_error=5, timedout=0, 
> > errno=2
> > Jul 19 08:09:38 spock sendmail[20520]: ruleset=tls_server, 
> > arg1=SOFTWARE, relay=[127.0.0.1], reject=403 4.7.0TLS handshake.
> > Jul 19 08:09:38 spock sendmail[20520]: j6J69cMx020520: to=<edited>, 
> > ctladdr=<edited> (48/48), delay=00:00:00, xdelay=00:00:00, 
> > mailer=relay, pri=30874, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, 
> > stat=Deferred: 403 4.7.0 TLS handshake.
> > Jul 19 08:09:38 spock sendmail[20521]: STARTTLS=server, error: accept 
> > failed=0, SSL_error=5, timedout=0,errno=0
> > Jul 19 08:09:38 spock sendmail[20521]: j6J69cai020521: localhost 
> > [127.0.0.1] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
> >
> > audit2allow -d -l
> > allow system_mail_t random_device_t:chr_file getattr;
> > allow system_mail_t urandom_device_t:chr_file getattr;
> >
> > Policy rpm installed: selinux-policy-targeted-1.25.1-9.noarch.rpm
> >
>  <snip>
>
>  I've installed selinux-policy-targeted-sources-1.25.1-9.noarch.rpm, 
>  edited
>  /etc/selinux/targeted/src/policy/domains/misc/local.te to contain:
>
>  allow system_mail_t random_device_t:chr_file getattr;
>  allow system_mail_t urandom_device_t:chr_file getattr;
>
>  Then did a 'make reload' in /etc/selinux/targeted/src/policy as per 
>  instructions I found on the net.
>  This made the sendmail TLS errors go away, however, trying smtp auth 
>  saslauthd complains instead:
>
>  Jul 19 14:14:19 spock saslauthd[22499]: do_auth         : auth 
>  failure: [user=<edited>] [service=smtp] [realm=] [mech=shadow] 
>  [reason=Unknown]
>  Jul 19 14:14:19 spock saslauthd[22500]: do_auth         : auth 
>  failure: [user=<edited>] [service=smtp] [realm=] [mech=shadow] 
>  [reason=Unknown]
>
>  'setenforce 0' makes it all work. No avc's in the logs during 
>  enforcing mode.
>
>  I guess my pathetic attempts at creating local rules failed misserably :(
>  I'm in way over my head here I think... Any pointers?
>  /Nicke
>  
No, you are seeing a new problem.

See if you can do the following
setsebool -P allow_saslauthd_read_shadow=1

If that is not in your current policy you might need to update it.

Dan




--

[Nicklas Norling]

Daniel J Walsh wrote:

>  Nicklas Norling wrote:
>
> > Nicklas Norling wrote:
> >
> >> <snip>
> >> Since 01:22:00 this day my server is in enforce mode. The only thing 
> >> I've found so far is sendmail being denied access to urandom and 
> >> random. I have sendmail setup with SMTP AUTH as well as certs for 
> >> performing STARTTLS with any TLS-able connecting MTA.
> >>
> >> /var/log/messages
> >> Jul 19 08:09:38 spock kernel: audit(1121753378.808:188): avc:  
> >> denied  { getattr } for  pid=20520 comm="sendmail"
> name="urandom" 
> >> dev=tmpfs ino=846 
> >> scontext=root:system_r:system_mail_ttcontext=system_u:object_r:urandom_device_t 
> >> tclass=chr_file
> >> Jul 19 08:09:38 spock kernel: audit(1121753378.808:189): avc:  
> >> denied  { getattr } for  pid=20520 comm="sendmail"
> name="random" 
> >> dev=tmpfs ino=844 
> >> scontext=root:system_r:system_mail_ttcontext=system_u:object_r:random_device_t 
> >> tclass=chr_file
> >>
> >> /var/log/maillog
> >> Jul 19 08:09:38 spock sendmail[20520]: j6J69cMx020520: 
> >> from=<edited>, size=874, class=0, nrcpts=1, 
> >> msgid=&lt;bd1035dcc05d7b2d6a16b046ae4bdd04(a)www.exinor.net&gt;, 
> >> bodytype=8BITMIME, relay=apache@localhost
> >> Jul 19 08:09:38 spock sendmail[20520]: j6J69cMx020520: 
> >> STARTTLS=client, error: connect failed=-1, SSL_error=5, timedout=0, 
> >> errno=2
> >> Jul 19 08:09:38 spock sendmail[20520]: ruleset=tls_server, 
> >> arg1=SOFTWARE, relay=[127.0.0.1], reject=403 4.7.0TLS handshake.
> >> Jul 19 08:09:38 spock sendmail[20520]: j6J69cMx020520: to=<edited>, 
> >> ctladdr=<edited> (48/48), delay=00:00:00, xdelay=00:00:00, 
> >> mailer=relay, pri=30874, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, 
> >> stat=Deferred: 403 4.7.0 TLS handshake.
> >> Jul 19 08:09:38 spock sendmail[20521]: STARTTLS=server, error: 
> >> accept failed=0, SSL_error=5, timedout=0,errno=0
> >> Jul 19 08:09:38 spock sendmail[20521]: j6J69cai020521: localhost 
> >> [127.0.0.1] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
> >>
> >> audit2allow -d -l
> >> allow system_mail_t random_device_t:chr_file getattr;
> >> allow system_mail_t urandom_device_t:chr_file getattr;
> >>
> >> Policy rpm installed: selinux-policy-targeted-1.25.1-9.noarch.rpm
> >>
> > <snip>
> >
> > I've installed selinux-policy-targeted-sources-1.25.1-9.noarch.rpm, 
> > edited
> > /etc/selinux/targeted/src/policy/domains/misc/local.te to contain:
> >
> > allow system_mail_t random_device_t:chr_file getattr;
> > allow system_mail_t urandom_device_t:chr_file getattr;
> >
> > Then did a 'make reload' in /etc/selinux/targeted/src/policy as per 
> > instructions I found on the net.
> > This made the sendmail TLS errors go away, however, trying smtp auth 
> > saslauthd complains instead:
> >
> > Jul 19 14:14:19 spock saslauthd[22499]: do_auth         : auth 
> > failure: [user=<edited>] [service=smtp] [realm=] [mech=shadow] 
> > [reason=Unknown]
> > Jul 19 14:14:19 spock saslauthd[22500]: do_auth         : auth 
> > failure: [user=<edited>] [service=smtp] [realm=] [mech=shadow] 
> > [reason=Unknown]
> >
> > 'setenforce 0' makes it all work. No avc's in the logs during 
> > enforcing mode.
> >
> > I guess my pathetic attempts at creating local rules failed 
> > misserably :(
> > I'm in way over my head here I think... Any pointers?
> > /Nicke
> >
>  No, you are seeing a new problem.
>
>  See if you can do the following
>  setsebool -P allow_saslauthd_read_shadow=1
>
>  If that is not in your current policy you might need to update it.
>
>  Dan
>  
I've set the boolean and turned enforcing back on. Mail works as expected :)
Thanks a lot for all the help Daniel!
Yet another system securer :)
/Nicke

Shared data are (was: A few permission problems)

[Paul Howarth]

On Tue, 2005-07-19 at 13:12 +0200, Nicklas Norling wrote:
>  I would encourage a boolean for shared data location. I think
> labeling a 
>  folder and it's subcontent with a specific label and then have different 
>  services be able to use it might be a start. That way I could disallow 
>  smb the rights but allow ftpd and httpd (as an example). I think that 
>  would be a great improvment from my point of view. 
I think this is a great idea. I have a file server at home where I stick
all the software I've downloaded, some for Linux and some for Windows.
The Windows box accesses the area using samba and Linux uses httpd as
I've set up a local yum repo for the Linux software. So in Niklas' idea
I'd be enabling httpd and smb for this and not ftp.

This type might be a good one to use for everything under /srv...

Paul.
-- 
Paul Howarth <paul(a)city-fan.org&gt;

Shared data are

[Daniel J Walsh]

Paul Howarth wrote:

> On Tue, 2005-07-19 at 13:12 +0200, Nicklas Norling wrote:
>   
>
> >I would encourage a boolean for shared data location. I think labeling a 
> >folder and it's subcontent with a specific label and then have different 
> >services be able to use it might be a start. That way I could disallow 
> >smb the rights but allow ftpd and httpd (as an example). I think that 
> >would be a great improvment from my point of view.
> >    
> >
>
> I think this is a great idea. I have a file server at home where I stick
> all the software I've downloaded, some for Linux and some for Windows.
> The Windows box accesses the area using samba and Linux uses httpd as
> I've set up a local yum repo for the Linux software. So in Niklas' idea
> I'd be enabling httpd and smb for this and not ftp.
>
> This type might be a good one to use for everything under /srv...
>
> Paul.
>   
>  
Ok.  I am allowing ftpd, samba, apache and/or apache scripts, rsync to 
read ftpd_anon_t.

So if you want files shared by these services, you can change the 
context to ftpd_anon_t.


--

Shared data area

[Paul Howarth]

Daniel J Walsh wrote:
>  Paul Howarth wrote:
>  
> > On Tue, 2005-07-19 at 13:12 +0200, Nicklas Norling wrote:
> >  
> >
> >> I would encourage a boolean for shared data location. I think 
> >> labeling a folder and it's subcontent with a specific label and then 
> >> have different services be able to use it might be a start. That way 
> >> I could disallow smb the rights but allow ftpd and httpd (as an 
> >> example). I think that would be a great improvment from my point of 
> >> view.
> >>   
> >
> >
> > I think this is a great idea. I have a file server at home where I stick
> > all the software I've downloaded, some for Linux and some for Windows.
> > The Windows box accesses the area using samba and Linux uses httpd as
> > I've set up a local yum repo for the Linux software. So in Niklas' idea
> > I'd be enabling httpd and smb for this and not ftp.
> >
> > This type might be a good one to use for everything under /srv...
> >
> > Paul.
> >  
> >
>  Ok.  I am allowing ftpd, samba, apache and/or apache scripts, rsync to 
>  read ftpd_anon_t.
>  
>  So if you want files shared by these services, you can change the 
>  context to ftpd_anon_t. 
Would it not be better to create a new type for a shared data area (e.g. 
srv_data_t), with booleans allowing read/write access to this data for 
each daemon, rather than overloading an existing type? After all, some 
process has to set up this data area, and for some people that will be 
done using ftp, some sftp, some rsync, some samba etc...

Obviously this is much harder to do but I thought I'd ask anyway :-)

Paul.

Shared data area

[Daniel J Walsh]

Paul Howarth wrote:

>  Daniel J Walsh wrote:
>
> > Paul Howarth wrote:
> >
> >> On Tue, 2005-07-19 at 13:12 +0200, Nicklas Norling wrote:
> >>  
> >>
> >>> I would encourage a boolean for shared data location. I think 
> >>> labeling a folder and it's subcontent with a specific label and 
> >>> then have different services be able to use it might be a start. 
> >>> That way I could disallow smb the rights but allow ftpd and httpd 
> >>> (as an example). I think that would be a great improvment from my 
> >>> point of view.
> >>>   
> >>
> >>
> >>
> >> I think this is a great idea. I have a file server at home where I 
> >> stick
> >> all the software I've downloaded, some for Linux and some for Windows.
> >> The Windows box accesses the area using samba and Linux uses httpd as
> >> I've set up a local yum repo for the Linux software. So in Niklas' idea
> >> I'd be enabling httpd and smb for this and not ftp.
> >>
> >> This type might be a good one to use for everything under /srv...
> >>
> >> Paul.
> >>  
> >>
> > Ok.  I am allowing ftpd, samba, apache and/or apache scripts, rsync 
> > to read ftpd_anon_t.
> >
> > So if you want files shared by these services, you can change the 
> > context to ftpd_anon_t.
>
>
>  Would it not be better to create a new type for a shared data area 
>  (e.g. srv_data_t), with booleans allowing read/write access to this 
>  data for each daemon, rather than overloading an existing type? After 
>  all, some process has to set up this data area, and for some people 
>  that will be done using ftp, some sftp, some rsync, some samba etc...
>  
I could do that, but I was already sharing the type between rsync and 
ftp.  Basically I think of this type, as data available on the network 
requiring no authorization to read or for ftpd_anon_rw_t, to write.  
Creating a bunch of booleans for each daemon that might use the type, 
seems like a complexity for limited additional security.  If I have a 
server running apache and ftpd, I can't see what the difference if 
allowing them to read the data via the ftp protocol, but not via the 
http protocol.  But I am willing to be persuaded.

>  Obviously this is much harder to do but I thought I'd ask anyway
> :-)
>
>  Paul.
>
>  -- 
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  http://www.redhat.com/mailman/listinfo/fedora-selinux-list 


--

Shared data area

[Paul Howarth]

On Wed, 2005-07-20 at 13:34 -0400, Daniel J Walsh wrote:
>  Paul Howarth wrote:
>  
>  > Daniel J Walsh wrote:
>  >
>  >> Paul Howarth wrote:
>  >>
>  >>> On Tue, 2005-07-19 at 13:12 +0200, Nicklas Norling wrote:
>  >>>  
>  >>>
>  >>>> I would encourage a boolean for shared data location. I think 
>  >>>> labeling a folder and it's subcontent with a specific label and 
>  >>>> then have different services be able to use it might be a start. 
>  >>>> That way I could disallow smb the rights but allow ftpd and httpd 
>  >>>> (as an example). I think that would be a great improvment from my 
>  >>>> point of view.
>  >>>>   
>  >>>
>  >>>
>  >>>
>  >>> I think this is a great idea. I have a file server at home where I 
>  >>> stick
>  >>> all the software I've downloaded, some for Linux and some for Windows.
>  >>> The Windows box accesses the area using samba and Linux uses httpd as
>  >>> I've set up a local yum repo for the Linux software. So in Niklas'
> idea
>  >>> I'd be enabling httpd and smb for this and not ftp.
>  >>>
>  >>> This type might be a good one to use for everything under /srv...
>  >>>
>  >>> Paul.
>  >>>  
>  >>>
>  >> Ok.  I am allowing ftpd, samba, apache and/or apache scripts, rsync 
>  >> to read ftpd_anon_t.
>  >>
>  >> So if you want files shared by these services, you can change the 
>  >> context to ftpd_anon_t.
>  >
>  >
>  > Would it not be better to create a new type for a shared data area 
>  > (e.g. srv_data_t), with booleans allowing read/write access to this 
>  > data for each daemon, rather than overloading an existing type? After 
>  > all, some process has to set up this data area, and for some people 
>  > that will be done using ftp, some sftp, some rsync, some samba etc...
>  >
>  I could do that, but I was already sharing the type between rsync and 
>  ftp.  Basically I think of this type, as data available on the network 
>  requiring no authorization to read or for ftpd_anon_rw_t, to write.  
>  Creating a bunch of booleans for each daemon that might use the type, 
>  seems like a complexity for limited additional security.  If I have a 
>  server running apache and ftpd, I can't see what the difference if 
>  allowing them to read the data via the ftp protocol, but not via the 
>  http protocol.  But I am willing to be persuaded. 
I'd agree on the read side of the discussion. But if you want to
maintain this data area using, say, rsync, then you'd need to use
ftpd_anon_rw_t to enable writing in the first place, and that would then
open up the area to be written by *all* of the daemons unless there were
separate write-enable booleans for each daemon. I can certainly see
benefits in doing that.

Paul.
-- 
Paul Howarth <paul(a)city-fan.org&gt;

Shared data area

[Nicklas Norling]

Paul Howarth wrote:

> On Wed, 2005-07-20 at 13:34 -0400, Daniel J Walsh wrote:
>   
>
> >Paul Howarth wrote:
> >
> >    
> >
> >>Daniel J Walsh wrote:
> >>
> >>      
> >>
> >>>Paul Howarth wrote:
> >>>
> >>>        
> >>>
> >>>>On Tue, 2005-07-19 at 13:12 +0200, Nicklas Norling wrote:
> >>>> 
> >>>>
> >>>>          
> >>>>
> >>>>>I would encourage a boolean for shared data location. I think 
> >>>>>labeling a folder and it's subcontent with a specific label and 
> >>>>>then have different services be able to use it might be a start. 
> >>>>>That way I could disallow smb the rights but allow ftpd and httpd 
> >>>>>(as an example). I think that would be a great improvment from my 
> >>>>>point of view.
> >>>>>  
> >>>>>            
> >>>>>
> >>>>
> >>>>I think this is a great idea. I have a file server at home where I 
> >>>>stick
> >>>>all the software I've downloaded, some for Linux and some for
> Windows.
> >>>>The Windows box accesses the area using samba and Linux uses httpd as
> >>>>I've set up a local yum repo for the Linux software. So in Niklas'
> idea
> >>>>I'd be enabling httpd and smb for this and not ftp.
> >>>>
> >>>>This type might be a good one to use for everything under /srv...
> >>>>
> >>>>Paul.
> >>>> 
> >>>>
> >>>>          
> >>>>
> >>>Ok.  I am allowing ftpd, samba, apache and/or apache scripts, rsync 
> >>>to read ftpd_anon_t.
> >>>
> >>>So if you want files shared by these services, you can change the 
> >>>context to ftpd_anon_t.
> >>>        
> >>>
> >>Would it not be better to create a new type for a shared data area 
> >>(e.g. srv_data_t), with booleans allowing read/write access to this 
> >>data for each daemon, rather than overloading an existing type? After 
> >>all, some process has to set up this data area, and for some people 
> >>that will be done using ftp, some sftp, some rsync, some samba etc...
> >>
> >>      
> >>
> >I could do that, but I was already sharing the type between rsync and 
> >ftp.  Basically I think of this type, as data available on the network 
> >requiring no authorization to read or for ftpd_anon_rw_t, to write.  
> >Creating a bunch of booleans for each daemon that might use the type, 
> >seems like a complexity for limited additional security.  If I have a 
> >server running apache and ftpd, I can't see what the difference if 
> >allowing them to read the data via the ftp protocol, but not via the 
> >http protocol.  But I am willing to be persuaded.
> >    
> >
>
> I'd agree on the read side of the discussion. But if you want to
> maintain this data area using, say, rsync, then you'd need to use
> ftpd_anon_rw_t to enable writing in the first place, and that would then
> open up the area to be written by *all* of the daemons unless there were
> separate write-enable booleans for each daemon. I can certainly see
> benefits in doing that.
>
> Paul.
>   
>  
I suppose one could argue that the daemon in question should be set up 
correctly. read-only or read-write as appropriate. Selinux should not do 
the applications job or there would be dual systems to keep in sync when 
policies changes. But I do see your point. I'm afraid I don't know 
enough about selinux to comment further. Just wanteded to play the 
devils advocate for awhile.
/Nicke

Shared data area

[Daniel J Walsh]

Nicklas Norling wrote:

>  Paul Howarth wrote:
>
> > On Wed, 2005-07-20 at 13:34 -0400, Daniel J Walsh wrote:
> >  
> >
> >> Paul Howarth wrote:
> >>
> >>   
> >>
> >>> Daniel J Walsh wrote:
> >>>
> >>>     
> >>>
> >>>> Paul Howarth wrote:
> >>>>
> >>>>       
> >>>>
> >>>>> On Tue, 2005-07-19 at 13:12 +0200, Nicklas Norling wrote:
> >>>>>
> >>>>>
> >>>>>         
> >>>>>
> >>>>>> I would encourage a boolean for shared data location. I think 
> >>>>>> labeling a folder and it's subcontent with a specific label
> and 
> >>>>>> then have different services be able to use it might be a start.
>
> >>>>>> That way I could disallow smb the rights but allow ftpd and 
> >>>>>> httpd (as an example). I think that would be a great improvment 
> >>>>>> from my point of view.
> >>>>>>  
> >>>>>>           
> >>>>>
> >>>>>
> >>>>> I think this is a great idea. I have a file server at home where 
> >>>>> I stick
> >>>>> all the software I've downloaded, some for Linux and some for 
> >>>>> Windows.
> >>>>> The Windows box accesses the area using samba and Linux uses 
> >>>>> httpd as
> >>>>> I've set up a local yum repo for the Linux software. So in 
> >>>>> Niklas' idea
> >>>>> I'd be enabling httpd and smb for this and not ftp.
> >>>>>
> >>>>> This type might be a good one to use for everything under /srv...
> >>>>>
> >>>>> Paul.
> >>>>>
> >>>>>
> >>>>>         
> >>>>
> >>>> Ok.  I am allowing ftpd, samba, apache and/or apache scripts, 
> >>>> rsync to read ftpd_anon_t.
> >>>>
> >>>> So if you want files shared by these services, you can change the 
> >>>> context to ftpd_anon_t.
> >>>>       
> >>>
> >>> Would it not be better to create a new type for a shared data area 
> >>> (e.g. srv_data_t), with booleans allowing read/write access to this 
> >>> data for each daemon, rather than overloading an existing type? 
> >>> After all, some process has to set up this data area, and for some 
> >>> people that will be done using ftp, some sftp, some rsync, some 
> >>> samba etc...
> >>>
> >>>     
> >>
> >> I could do that, but I was already sharing the type between rsync 
> >> and ftp.  Basically I think of this type, as data available on the 
> >> network requiring no authorization to read or for ftpd_anon_rw_t, to 
> >> write.  Creating a bunch of booleans for each daemon that might use 
> >> the type, seems like a complexity for limited additional security.  
> >> If I have a server running apache and ftpd, I can't see what the 
> >> difference if allowing them to read the data via the ftp protocol, 
> >> but not via the http protocol.  But I am willing to be persuaded.
> >>   
> >
> >
> > I'd agree on the read side of the discussion. But if you want to
> > maintain this data area using, say, rsync, then you'd need to use
> > ftpd_anon_rw_t to enable writing in the first place, and that would then
> > open up the area to be written by *all* of the daemons unless there were
> > separate write-enable booleans for each daemon. I can certainly see
> > benefits in doing that.
> >
> > Paul.
> >  
> >
>  I suppose one could argue that the daemon in question should be set up 
>  correctly. read-only or read-write as appropriate. Selinux should not 
>  do the applications job or there would be dual systems to keep in sync 
>  when policies changes. But I do see your point. I'm afraid I don't 
>  know enough about selinux to comment further. Just wanteded to play 
>  the devils advocate for awhile.
>  /Nicke
>  
Ok, I will add booleans for all "shared" domains to write to
ftpd_anon_rw_t

>  -- 
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  http://www.redhat.com/mailman/listinfo/fedora-selinux-list 


--