More avc denies

[Leonard den Ottolander]

Hi,

With the latest updates on a FC2t3 setup with SELinux running in
permissive mode I am still seeing avc errors. Kernel-2.6.5-1.358,
policy-1.11.3-3. Had to move in the /etc/security/selinux/policies
because they were created as .rpmnews.

System startup:
avc:  denied  { read } for  pid=546 exe=/sbin/lvm.static name=dri
dev=hda2 ino=84499 scontext=system_u:system_r:lvm_t
tcontext=system_u:object_r:dri_device_t tclass=dir
avc:  denied  { search } for  pid=546 exe=/sbin/lvm.static name=dri
dev=hda2 ino=84499 scontext=system_u:system_r:lvm_t
tcontext=system_u:object_r:dri_device_t tclass=dir

Root console login:
avc:  denied  { read } for  pid=1559 exe=/bin/login
name=.default_contexts dev=hda2 ino=437194
scontext=system_u:system_r:local_login_t
tcontext=root:object_r:staff_home_dir_t tclass=file
avc:  denied  { getattr } for  pid=1559 exe=/bin/login
path=/root/.default_contexts dev=hda2 ino=437194
scontext=system_u:system_r:local_login_t
tcontext=root:object_r:staff_home_dir_t tclass=file

ntpdate <server>:
avc:  denied  { getattr } for  pid=1759 exe=/usr/sbin/ntpdate
path=/dev/tty1 dev=hda2 ino=71082 scontext=root:system_r:ntpd_t
tcontext=root:object_r:sysadm_tty_device_t tclass=chr_file
avc:  denied  { ioctl } for  pid=1759 exe=/usr/sbin/ntpdate
path=/dev/tty1 dev=hda2 ino=71082 scontext=root:system_r:ntpd_t
tcontext=root:object_r:sysadm_tty_device_t tclass=chr_file

Daily cron (webalizer?):
avc:  denied  { read } for  pid=1818 exe=/bin/cat name=access_log
dev=hda2 ino=390310 scontext=system_u:system_r:system_crond_t
tcontext=root:object_r:httpd_log_t tclass=file

and 20 secs later:
avc:  denied  { execute_no_trans } for  pid=1960 exe=/usr/sbin/prelink
path=/lib/ld-2.3.3.so dev=hda2 ino=32386
scontext=system_u:system_r:prelink_t tcontext=system_u:object_r:ld_so_t
tclass=file

ssh login and su - :
avc:  denied  { read } for  pid=3489 exe=/bin/su name=.default_contexts
dev=hda2 ino=437194 scontext=user_u:user_r:user_su_t
tcontext=root:object_r:staff_home_dir_t tclass=file
avc:  denied  { getattr } for  pid=3489 exe=/bin/su
path=/root/.default_contexts dev=hda2 ino=437194
scontext=user_u:user_r:user_su_t tcontext=root:object_r:staff_home_dir_t
tclass=file

avc:  denied  { add_name } for  pid=3489 exe=/bin/su name=.xauthrQsUjb
scontext=user_u:user_r:user_su_t tcontext=root:object_r:staff_home_dir_t
tclass=dir
avc:  denied  { create } for  pid=3489 exe=/bin/su name=.xauthrQsUjb
scontext=user_u:user_r:user_su_t
tcontext=user_u:object_r:staff_home_dir_t tclass=file
avc:  denied  { setattr } for  pid=3489 exe=/bin/su name=.xauthrQsUjb
dev=hda2 ino=437207 scontext=user_u:user_r:user_su_t
tcontext=user_u:object_r:staff_home_dir_t tclass=file

And when setenforce 1 I get tons of prelink execute_no_trans errors for
prelink on /lib/ld-2.3.3.so .

Maybe some of these are expected behaviour, but then a few aren't :) .

Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research

[Tim Waugh]

On Mon, May 10, 2004 at 04:04:04PM +0200, Leonard den Ottolander wrote:

>  Had to move in the /etc/security/selinux/policies because they were
>  created as .rpmnews. 
You had policy-sources installed as well?  I think it's expected
behaviour in that case (policy-sources' %post scriptlet generates them
from source).

>  Root console login:
>  avc:  denied  { read } for  pid=1559 exe=/bin/login
>  name=.default_contexts dev=hda2 ino=437194
>  scontext=system_u:system_r:local_login_t
>  tcontext=root:object_r:staff_home_dir_t tclass=file 
Looks like /root/.default_contexts has the wrong file context.  Try after
running restorecon on it.

>  ssh login and su - :
>  avc:  denied  { read } for  pid=3489 exe=/bin/su name=.default_contexts
>  dev=hda2 ino=437194 scontext=user_u:user_r:user_su_t
>  tcontext=root:object_r:staff_home_dir_t tclass=file
>  avc:  denied  { getattr } for  pid=3489 exe=/bin/su
>  path=/root/.default_contexts dev=hda2 ino=437194
>  scontext=user_u:user_r:user_su_t tcontext=root:object_r:staff_home_dir_t
>  tclass=file 
See above.

>  avc:  denied  { add_name } for  pid=3489 exe=/bin/su
> name=.xauthrQsUjb
>  scontext=user_u:user_r:user_su_t tcontext=root:object_r:staff_home_dir_t
>  tclass=dir
>  avc:  denied  { create } for  pid=3489 exe=/bin/su name=.xauthrQsUjb
>  scontext=user_u:user_r:user_su_t
>  tcontext=user_u:object_r:staff_home_dir_t tclass=file
>  avc:  denied  { setattr } for  pid=3489 exe=/bin/su name=.xauthrQsUjb
>  dev=hda2 ino=437207 scontext=user_u:user_r:user_su_t
>  tcontext=user_u:object_r:staff_home_dir_t tclass=file 
This is in bugzilla already:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120108

Tim.
*/

[Leonard den Ottolander]

Hi Tim,

And what about the ntpdate errors?

ntpdate <server>:
avc:  denied  { getattr } for  pid=1759 exe=/usr/sbin/ntpdate
path=/dev/tty1 dev=hda2 ino=71082 scontext=root:system_r:ntpd_t
tcontext=root:object_r:sysadm_tty_device_t tclass=chr_file
avc:  denied  { ioctl } for  pid=1759 exe=/usr/sbin/ntpdate
path=/dev/tty1 dev=hda2 ino=71082 scontext=root:system_r:ntpd_t
tcontext=root:object_r:sysadm_tty_device_t tclass=chr_file

And cron.daily?

avc:  denied  { read } for  pid=1818 exe=/bin/cat name=access_log
dev=hda2 ino=390310 scontext=system_u:system_r:system_crond_t
tcontext=root:object_r:httpd_log_t tclass=file

and 20 secs later in cron:

avc:  denied  { execute_no_trans } for  pid=1960 exe=/usr/sbin/prelink
path=/lib/ld-2.3.3.so dev=hda2 ino=32386
scontext=system_u:system_r:prelink_t tcontext=system_u:object_r:ld_so_t
tclass=file

Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research

[Tim Waugh]

On Mon, May 10, 2004 at 06:02:04PM +0200, Leonard den Ottolander wrote:

>  And what about the ntpdate errors?
>  And cron.daily?
>  and 20 secs later in cron: 
(I didn't reply to those, since I know nothing about them..)

Tim.
*/

[Leonard den Ottolander]

Hi Tim,

>  > And what about the ntpdate errors?
>  > And cron.daily?
>  > and 20 secs later in cron:
>  
>  (I didn't reply to those, since I know nothing about them..) 
That's alright. The fact that I am greeting you in my reply does not
mean that I expect you personally to answer these questions (this seems
to confuse more people). It was more of a status update for others who
might be following the thread.

Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research

Also more avc denies - up2date

[Bob Gustafson]

Also, when I try to run up2date from Gnome (started as user1) by clicking
on the toolbar icon -> then clicking on 'Open up2date', then putting in
root password in resulting dialog box, nothing happens after that

  [user1@hoho2 user1]$ dmesg | tail -2  ...

  audit(1084213893.132:0): avc:  denied  { name_bind } for  pid=3830
  exe=/usr/X11R6/bin/Xorg scontext=user_u:user_r:user_xserver_t
  tcontext=system_u:object_r:vnc_port_t tclass=tcp_socket

  audit(1084213926.790:0): avc:  denied  { transition } for  pid=3991
  exe=/usr/sbin/userhelper path=/usr/sbin/up2date dev=sda2 ino=3845328
  scontext=user_u:user_r:user_userhelper_t tcontext=root:sysadm_r:rpm_t
  tclass=process

  [user1@hoho2 user1]$

However, if I open a terminal window and do 'setenforce 0', and then repeat
the above commands, the up2date splash opens and I can then go ahead and
download updates (if there are any).

It looks like the policy needs a tweek here, or maybe the problem is in Gnome?

BobG

Also more avc denies - up2date

[Leonard den Ottolander]

Hi Bob,

>  Also, when I try to run up2date from Gnome (started as user1) by
> clicking
>  on the toolbar icon -> then clicking on 'Open up2date', then putting in
>  root password in resulting dialog box, nothing happens after that 
This is already in bugzilla: cannot run up2date as user_r or staff_r
(http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122712).

Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research

[Thomas Molina]

On Mon, 10 May 2004, Tim Waugh wrote:

>  On Mon, May 10, 2004 at 04:04:04PM +0200, Leonard den Ottolander
> wrote:
>  
>  > Had to move in the /etc/security/selinux/policies because they were
>  > created as .rpmnews.
>  
>  You had policy-sources installed as well?  I think it's expected
>  behaviour in that case (policy-sources' %post scriptlet generates them
>  from source). 
I must be having a senior moment because I looked in the above directory 
and managed to confuse myself.  If the rpmnew files are the newer files, 
why do they have the older date/time?  Here is my ls:

[root@dad selinux]# ls -la
total 43600
drwxr-xr-x  3 root root    4096 May  8 19:35 .
drwxr-xr-x  4 root root    4096 May  8 19:35 ..
-rw-r--r--  1 root root   86792 May  8 19:35 file_contexts
-rw-r--r--  1 root root   88017 Apr 28 22:04 file_contexts.rpmnew
-rw-r--r--  1 root root 7383775 May  8 19:35 policy.15
-rw-r--r--  1 root root 7383775 May  7 11:24 policy.15.rpmnew
-rw-r--r--  1 root root 7385512 May  8 19:35 policy.16
-rw-r--r--  1 root root 7385512 May  7 11:24 policy.16.rpmnew
-rw-r--r--  1 root root 7385824 May  8 19:35 policy.17
-rw-r--r--  1 root root 7385824 May  7 11:24 policy.17.rpmnew
drwx------  3 root root    4096 May  7 11:24 src

[Richard Hally]

Thomas Molina wrote:

>  
>  On Mon, 10 May 2004, Tim Waugh wrote:
>  
>  
> >On Mon, May 10, 2004 at 04:04:04PM +0200, Leonard den Ottolander wrote:
> >
> >
> >>Had to move in the /etc/security/selinux/policies because they were
> >>created as .rpmnews.
> >
> >You had policy-sources installed as well?  I think it's expected
> >behaviour in that case (policy-sources' %post scriptlet generates them
> >from source).
>  
>  
>  I must be having a senior moment because I looked in the above directory 
>  and managed to confuse myself.  If the rpmnew files are the newer files, 
>  why do they have the older date/time?  Here is my ls:
>  
>  [root@dad selinux]# ls -la
>  total 43600
>  drwxr-xr-x  3 root root    4096 May  8 19:35 .
>  drwxr-xr-x  4 root root    4096 May  8 19:35 ..
>  -rw-r--r--  1 root root   86792 May  8 19:35 file_contexts
>  -rw-r--r--  1 root root   88017 Apr 28 22:04 file_contexts.rpmnew
>  -rw-r--r--  1 root root 7383775 May  8 19:35 policy.15
>  -rw-r--r--  1 root root 7383775 May  7 11:24 policy.15.rpmnew
>  -rw-r--r--  1 root root 7385512 May  8 19:35 policy.16
>  -rw-r--r--  1 root root 7385512 May  7 11:24 policy.16.rpmnew
>  -rw-r--r--  1 root root 7385824 May  8 19:35 policy.17
>  -rw-r--r--  1 root root 7385824 May  7 11:24 policy.17.rpmnew
>  drwx------  3 root root    4096 May  7 11:24 src
>   
When the policy rpm is installed(or updated) it puts the .rpmnew files 
in place. (the date is from when they were built on the build system). 
Then the policy-source package is installed and the files (policy.n and 
file_contexts) are built as part of the install(or update).

  I always delete the .rpmnew file.

HTH
Richard Hally

[Bob Gustafson]

On Tue, 11 May 2004 14:38:41 -0400 Richard Hally wrote:
>   I always delete the .rpmnew file.
>
> HTH 
Well, that's good to know.

I think I just renamed the .rpmnew file over the plain..

BobG

[Thomas Molina]

>  When the policy rpm is installed(or updated) it puts the .rpmnew
> files 
>  in place. (the date is from when they were built on the build system). 
>  Then the policy-source package is installed and the files (policy.n and 
>  file_contexts) are built as part of the install(or update).
>  
>    I always delete the .rpmnew file. 
OK, so now I am confused again.  I moved all the rpmnew files to /tmp and 
did an rpm -V policy.  I got the following:

[root@dad root]# rpm -V policy
.......TC c /etc/security/default_contexts
.......TC c /etc/security/default_type
.......TC c /etc/security/failsafe_context
.......TC c /etc/security/initrc_context
S.5....TC c /etc/security/selinux/file_contexts
..5....T. c /etc/security/selinux/policy.15
..5....T. c /etc/security/selinux/policy.16
..5....T. c /etc/security/selinux/policy.17
.......TC c /root/.default_contexts

Then I moved the "regular" files to /tmp and moved the rpmnew files into 
their places and got the following:

[root@dad root]# rpm -V policy
.......TC c /etc/security/default_contexts
.......TC c /etc/security/default_type
.......TC c /etc/security/failsafe_context
.......TC c /etc/security/initrc_context
.......T. c /etc/security/selinux/file_contexts
.......TC c /root/.default_contexts

Which seems to indicate that the rpmnew files should be copied over the 
"old" files.  As I recall, there are rpmorig and rpmnew files that get 
installed with an rpm.  rpmorig files are put into place when the new 
config file replaces the old one and the old one is saved as the rpmorig.  
The rpmnew file should then be where the old file is kept in place, but 
the new file is saved "on the side".  

Is there "official" word?

This is really dumb that this bugs me this much.

[Leonard den Ottolander]

Hello Thomas,

>  OK, so now I am confused again.  I moved all the rpmnew files to /tmp
> and 
>  did an rpm -V policy.  I got the following: 
The problem is that policy and policy-sources somewhat conflict. In case
both are installed the policy files will be added as .rpmnew, and the
policies are recreated from policy-sources. These recreated policies
should be identical in function with those from policy, but don't
necessarily have the same checksum. (Not sure what happens on an update
of policy-sources when you edited them, I guess policy-sources will then
be installed as .rpmnew as well).

Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research

policy and policy-source confusion

[Thomas Molina]

On Wed, 12 May 2004, Leonard den Ottolander wrote:

>  Hello Thomas,
>  
>  > OK, so now I am confused again.  I moved all the rpmnew files to /tmp and 
>  > did an rpm -V policy.  I got the following:
>  
>  The problem is that policy and policy-sources somewhat conflict. In case
>  both are installed the policy files will be added as .rpmnew, and the
>  policies are recreated from policy-sources. These recreated policies
>  should be identical in function with those from policy, but don't
>  necessarily have the same checksum. (Not sure what happens on an update
>  of policy-sources when you edited them, I guess policy-sources will then
>  be installed as .rpmnew as well). 
"somewhat conflict"?  What is that supposed to mean?  From my point of 
view, the current situation violates standard practice and the intent of 
the rpm system.  Actual practice doesn't match the docs either.  The FAQ 
says: 

"Installing or updating the policy  package loads the new policy 
after it installs the files. Similarly, installing or updating the 
policy-sources package rebuilds the policy.<version>  file as well as the 
file_contexts  file, then loads them as the currently effective policy."

So if I have both policy and policy-sources, and update both the 
policy.version file gets rebuilt/installed twice?  That can't be right.

If the rpmnew files should just be deleted, they shouldn't even be created 
in the first place.  In this case the policy package validates with the 
wrong set of files in place.

In my opinion installing/updating one package shouldn't modify files 
belonging to another package.  If policy-source is going to do this it 
should be a specific action by the user post-installation, not a part of 
the installation process itself.

policy and policy-source confusion

[Leonard den Ottolander]

Hello Thomas,

>  If the rpmnew files should just be deleted, they shouldn't even
> be created 
>  in the first place.  In this case the policy package validates with the 
>  wrong set of files in place. 
This is not entirely true. If you for example upgrade apache httpd.conf
will also be installed as httpd.conf.rpmnew, to save your modified
config file.

>  In my opinion installing/updating one package shouldn't modify
> files 
>  belonging to another package.  If policy-source is going to do this it 
>  should be a specific action by the user post-installation, not a part of 
>  the installation process itself. 
I thought I saw this in bugzilla, but can't find it. Maybe on IRC?
Thread on fedora-test/-devel? Dunno. Anyway, there are others who think
policy and policy-sources should mutually exclude each other.

Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research

policy and policy-source confusion

[Aleksey Nogin]

On 12.05.2004 09:34, Leonard den Ottolander wrote:

> >In my opinion installing/updating one package shouldn't modify
> files 
> >belonging to another package.  If policy-source is going to do this it 
> >should be a specific action by the user post-installation, not a part of 
> >the installation process itself.
>  
>  
>  I thought I saw this in bugzilla, but can't find it. Maybe on IRC?
>  Thread on fedora-test/-devel? Dunno. Anyway, there are others who think
>  policy and policy-sources should mutually exclude each other. 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=118604

-- 
Aleksey Nogin

Home Page: http://nogin.org/
E-Mail: nogin(a)cs.caltech.edu (office), aleksey(a)nogin.org (personal)
Office: Jorgensen 70, tel: [phone]