FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Hardened

 
 
LinkBack Thread Tools
 
Old 08-27-2012, 05:38 PM
Sven Vermeulen
 
Default Can't get fully functional (kde) desktop with SELinux

On Sun, Aug 26, 2012 at 11:57:46AM +0200, Paolo Barile wrote:
> Hello Sven, first of all, all the denials I wrote here are from
> enforcing mode.

Oh that's good then. Would you also happen to get any failures from the
applications themselves (or error messages you get)?

Or, in other words, why shouldn't I just dontaudit everything

Getting the error messages is a very important and often misunderstood part.
It helps identify the reason why something needs to be allowed (since for
SELinux policies, we have several interfaces that allow something, but
depending on the reason why it needs to be allowed, we might need to use a
different interface) and also document the problem so the fix is easier to
submit upstream.

> >> Aug 25 18:06:05 dell-studio kernel: [ 8.028595] type=1400
> >> audit(1345917944.027:3): avc: denied { search } for pid=1433
> >> comm="alsactl" name="root" dev="sda5" ino=1308163
> >> scontext=system_u:system_r:alsa_t tcontext=system_ubject_r:default_t
> >> tclass=dir
> > This sais /root is default_t again. Mine sais:
> >
> > ~ # matchpathcon /root
> > /root rootbject_r:user_home_dir_t
> >
> > ~ # grep '/root' /etc/selinux/strict/contexts/files/file_contexts* | grep user_home_dir_t
> > /etc/selinux/strict/contexts/files/file_contexts.homedirs:/root -d rootbject_r:user_home_dir_t
>
> The same gives me nothing.

You'll need to change the directory from strict to targeted in your case.

The root users' home directory should definitely be mentioned here (just
checked on a targeted system at work). Is the root user mapped to a
particular SELinux user?

What does "semanage login -l" say?

[... Allowing global_ssp to allow domains access to urandom ...]
> No, it isn't. I did not enabled it because I'm still not in hardened
> because I'd want let selinux comletely work before the conversion.

That's okay. At least we now know that the domain probably needs it. Do you
only get the denials or also an error?

Wkr,
Sven Vermeulen
 
Old 08-27-2012, 06:28 PM
Paolo Barile
 
Default Can't get fully functional (kde) desktop with SELinux

On 27/08/2012 19:38, Sven Vermeulen wrote:
> On Sun, Aug 26, 2012 at 11:57:46AM +0200, Paolo Barile wrote:
>> Hello Sven, first of all, all the denials I wrote here are from
>> enforcing mode.
> Oh that's good then. Would you also happen to get any failures from the
> applications themselves (or error messages you get)?
>
> Or, in other words, why shouldn't I just dontaudit everything
>
> Getting the error messages is a very important and often misunderstood part.
> It helps identify the reason why something needs to be allowed (since for
> SELinux policies, we have several interfaces that allow something, but
> depending on the reason why it needs to be allowed, we might need to use a
> different interface) and also document the problem so the fix is easier to
> submit upstream.
Well I only had a policykit crash window. But It disappeared when,
following your suggestion, I've made a rule with audit2allow only on
the execute denials. But even with that rule the problems of audio card
and powerdevil weren't solved.
This is the rule:
require {
type policykit_exec_t;
type bin_t;
type crond_t;
type system_dbusd_t;
class file { execute execute_no_trans };
}

#============= crond_t ==============
allow crond_t bin_t:file { execute execute_no_trans };

#============= system_dbusd_t ==============
allow system_dbusd_t policykit_exec_t:file execute;

>
>>>> Aug 25 18:06:05 dell-studio kernel: [ 8.028595] type=1400
>>>> audit(1345917944.027:3): avc: denied { search } for pid=1433
>>>> comm="alsactl" name="root" dev="sda5" ino=1308163
>>>> scontext=system_u:system_r:alsa_t tcontext=system_ubject_r:default_t
>>>> tclass=dir
>>> This sais /root is default_t again. Mine sais:
>>>
>>> ~ # matchpathcon /root
>>> /root rootbject_r:user_home_dir_t
>>>
>>> ~ # grep '/root' /etc/selinux/strict/contexts/files/file_contexts* | grep user_home_dir_t
>>> /etc/selinux/strict/contexts/files/file_contexts.homedirs:/root -d rootbject_r:user_home_dir_t
>> The same gives me nothing.
> You'll need to change the directory from strict to targeted in your case.
>
> The root users' home directory should definitely be mentioned here (just
> checked on a targeted system at work). Is the root user mapped to a
> particular SELinux user?
>
> What does "semanage login -l" say?
Semanage login -l outputs only:
__default__ unconfined_u
system_u system_u

Anyway I think that I "solved" this problem (probably it's rather a
workaround) using the context you wrote: "semanage fcontext -a -t
user_home_dir_t /root". In fact the su delay disappeared.

>
> [... Allowing global_ssp to allow domains access to urandom ...]
>> No, it isn't. I did not enabled it because I'm still not in hardened
>> because I'd want let selinux comletely work before the conversion.
> That's okay. At least we now know that the domain probably needs it. Do you
> only get the denials or also an error?
>
> Wkr,
> Sven Vermeulen
>
Well, no, all what is related to alsactl is (perhaps) the fact that kde
can't see my audio card.

There is one more problem. As I wrote in the previous mail two folders
in /run are mislabeled: /run/ConsoleKit and /run/console. For the first,
the mislabeling was solved by using the script for the initramfs users
(of course addin restorecon -R /run). But I couldn't relabel permanently
the second dir. I think it's because it belongs to pam, so perhaps it is
created after a login, but the script runs before it. Am I right?
So how can it be solved? Why every boot mislabels these two directories?
I think that if we solve it then we can try to summarize the denials I
have at this point.

Paolo.
 
Old 08-28-2012, 05:27 PM
Sven Vermeulen
 
Default Can't get fully functional (kde) desktop with SELinux

On Mon, Aug 27, 2012 at 08:28:20PM +0200, Paolo Barile wrote:
> Well I only had a policykit crash window. But It disappeared when,
> following your suggestion, I've made a rule with audit2allow only on
> the execute denials. But even with that rule the problems of audio card
> and powerdevil weren't solved.
[...]

Okay. I'll take a look at the AVCs earlier and draft up a possible fix for
you to try out (you can use audit2allow but I'm not sure yet if the result
is correct or not).

> > What does "semanage login -l" say?
> Semanage login -l outputs only:
> __default__ unconfined_u
> system_u system_u
>
> Anyway I think that I "solved" this problem (probably it's rather a
> workaround) using the context you wrote: "semanage fcontext -a -t
> user_home_dir_t /root". In fact the su delay disappeared.

Looks like we need to declare the root user for unconfined_u anyhow. You
might want to run the following to do so:

~# semanage login -a -s unconfined_u root

It seems that genhomedircon (well, it's now part of the semodule command but
the genhomedircon command still works) only looks at users with a UID of 500
and more. By not explicitly declaring root as an interactive user, the tools
just ignore it (and as a result don't generate the proper contexts).

If you do that, then genhomedircon and then look at the output of the
following command again, I hope you get enough output?

~# grep root /etc/selinux/*/contexts/files/file_contexts.homedirs

> There is one more problem. As I wrote in the previous mail two folders
> in /run are mislabeled: /run/ConsoleKit and /run/console. For the first,
> the mislabeling was solved by using the script for the initramfs users
> (of course addin restorecon -R /run). But I couldn't relabel permanently
> the second dir. I think it's because it belongs to pam, so perhaps it is
> created after a login, but the script runs before it. Am I right?

Sounds probable. We'll need to figure out what is creating the console
directory. From the label (consolekit_var_run_t) I imagine it is something
of ConsoleKit.

I can probably create a named file transition for this. The ConsoleKit stuff
is acknowledged already, perhaps the /run/console is solved with something
like the following?

#v+
policy_module(localconsolekit, 1.0)

gen_require(`
type pam_var_console_t;
type consolekit_t;
')

files_pid_filetrans(consolekit_t, pam_var_console_t, dir, "console")
#v-

This basically sais that, if a domain "consolekit_t" creates a
dir(ectory) with name "console" in a location with label var_run_t ("pid"),
then that directory would be labeled "pam_var_console_t" immediately.

It is possible however that consolekit_t doesn't hold the rights to do so,
so you might need to add in:

#v+
create_dirs_pattern(consolekit_t, pam_var_console_t, pam_var_console_t)
#v-

Thanks for your patience on this so far ;-)

Wkr,
Sven Vermeulen
 
Old 08-29-2012, 04:36 PM
Paolo Barile
 
Default Can't get fully functional (kde) desktop with SELinux

On 28/08/2012 19:27, Sven Vermeulen wrote:
> On Mon, Aug 27, 2012 at 08:28:20PM +0200, Paolo Barile wrote:
>> Well I only had a policykit crash window. But It disappeared when,
>> following your suggestion, I've made a rule with audit2allow only on
>> the execute denials. But even with that rule the problems of audio card
>> and powerdevil weren't solved.
> [...]
>
> Okay. I'll take a look at the AVCs earlier and draft up a possible fix for
> you to try out (you can use audit2allow but I'm not sure yet if the result
> is correct or not).
Thank you very much. As for your question about error messages, i
noticed that starting kmix from shell gives me:

QDBusConnection: session D-Bus connection created before
QCoreApplication. Application may misbehave.

And kmix doesn't start.
>
>>> What does "semanage login -l" say?
>> Semanage login -l outputs only:
>> __default__ unconfined_u
>> system_u system_u
>>
>> Anyway I think that I "solved" this problem (probably it's rather a
>> workaround) using the context you wrote: "semanage fcontext -a -t
>> user_home_dir_t /root". In fact the su delay disappeared.
> Looks like we need to declare the root user for unconfined_u anyhow. You
> might want to run the following to do so:
>
> ~# semanage login -a -s unconfined_u root
>
> It seems that genhomedircon (well, it's now part of the semodule command but
> the genhomedircon command still works) only looks at users with a UID of 500
> and more. By not explicitly declaring root as an interactive user, the tools
> just ignore it (and as a result don't generate the proper contexts).
>
> If you do that, then genhomedircon and then look at the output of the
> following command again, I hope you get enough output?
>
> ~# grep root /etc/selinux/*/contexts/files/file_contexts.homedirs
Oh well, even too much perhaps now! I mean it contains strings like:

/root/.mozilla(/.*)? unconfined_ubject_r:mozilla_home_t

But I don't know why the root user should have rights for X
applications. Is that normal? If so, I think we can consider it solved!

Do you suggest to map to unconfined_u the other users too? I'm asking it
because I noticed a slowness in openening folders (in X) for the first
time after the login.

>
>> There is one more problem. As I wrote in the previous mail two folders
>> in /run are mislabeled: /run/ConsoleKit and /run/console. For the first,
>> the mislabeling was solved by using the script for the initramfs users
>> (of course addin restorecon -R /run). But I couldn't relabel permanently
>> the second dir. I think it's because it belongs to pam, so perhaps it is
>> created after a login, but the script runs before it. Am I right?
> Sounds probable. We'll need to figure out what is creating the console
> directory. From the label (consolekit_var_run_t) I imagine it is something
> of ConsoleKit.
>
> I can probably create a named file transition for this. The ConsoleKit stuff
> is acknowledged already, perhaps the /run/console is solved with something
> like the following?
>
> #v+
> policy_module(localconsolekit, 1.0)
>
> gen_require(`
> type pam_var_console_t;
> type consolekit_t;
> ')
>
> files_pid_filetrans(consolekit_t, pam_var_console_t, dir, "console")
> #v-
>
> This basically sais that, if a domain "consolekit_t" creates a
> dir(ectory) with name "console" in a location with label var_run_t ("pid"),
> then that directory would be labeled "pam_var_console_t" immediately.
>
> It is possible however that consolekit_t doesn't hold the rights to do so,
> so you might need to add in:
>
> #v+
> create_dirs_pattern(consolekit_t, pam_var_console_t, pam_var_console_t)
> #v-
>
> Thanks for your patience on this so far ;-)
>
> Wkr,
> Sven Vermeulen
>
Well thanks to you for the yours!
Anyway with that module (but the creat_dirs_pattern rule is necessary),
the /run/console situation is solved too.

Now let's try to summarize all the denials I have now at this point.

On boot I have:

Aug 29 18:07:34 dell-studio kernel: [ 8.446914] type=1400
audit(1346263638.445:4): avc: denied { getattr } for pid=1454
comm="alsactl" name="/" dev="tmpfs" ino=3130
scontext=system_u:system_r:alsa_t tcontext=system_ubject_r:tmpfs_t
tclass=filesystem
Aug 29 18:07:34 dell-studio kernel: [ 8.446939] type=1400
audit(1346263638.445:5): avc: denied { write } for pid=1454
comm="alsactl" name="shm" dev="tmpfs" ino=1124
scontext=system_u:system_r:alsa_t tcontext=system_ubject_r:device_t
tclass=dir
Aug 29 18:07:34 dell-studio kernel: [ 8.446947] type=1400
audit(1346263638.445:6): avc: denied { add_name } for pid=1454
comm="alsactl" name="pulse-shm-688087777"
scontext=system_u:system_r:alsa_t tcontext=system_ubject_r:device_t
tclass=dir
Aug 29 18:07:34 dell-studio kernel: [ 8.446963] type=1400
audit(1346263638.445:7): avc: denied { create } for pid=1454
comm="alsactl" name="pulse-shm-688087777"
scontext=system_u:system_r:alsa_t tcontext=system_ubject_r:device_t
tclass=file
Aug 29 18:07:34 dell-studio kernel: [ 8.446976] type=1400
audit(1346263638.445:8): avc: denied { read write open } for pid=1454
comm="alsactl" name="pulse-shm-688087777" dev="tmpfs" ino=3801
scontext=system_u:system_r:alsa_t tcontext=system_ubject_r:device_t
tclass=file
Aug 29 18:07:34 dell-studio kernel: [ 8.466988] type=1400
audit(1346263638.465:9): avc: denied { remove_name } for pid=1456
comm="alsactl" name="pulse-shm-2524473597" dev="tmpfs" ino=4125
scontext=system_u:system_r:alsa_t tcontext=system_ubject_r:device_t
tclass=dir
Aug 29 18:07:34 dell-studio kernel: [ 8.467011] type=1400
audit(1346263638.465:10): avc: denied { unlink } for pid=1456
comm="alsactl" name="pulse-shm-2524473597" dev="tmpfs" ino=4125
scontext=system_u:system_r:alsa_t tcontext=system_ubject_r:device_t
tclass=file
Aug 29 18:07:34 dell-studio kernel: [ 8.984725] type=1400
audit(1346256440.202:11): avc: denied { getattr } for pid=1538
comm="cryptsetup" name="/" dev="tmpfs" ino=3130
scontext=system_u:system_r:lvm_t tcontext=system_ubject_r:tmpfs_t
tclass=filesystem
Aug 29 18:07:34 dell-studio kernel: [ 14.683311] type=1400
audit(1346256445.900:15): avc: denied { module_request } for pid=1543
comm="cryptsetup" kmod="cbc(aes)" scontext=system_u:system_r:lvm_t
tcontext=system_u:system_r:kernel_t tclass=system
Aug 29 18:07:34 dell-studio kernel: [ 23.000643] type=1400
audit(1346256454.217:16): avc: denied { setrlimit } for pid=2008
comm="dbus-daemon" scontext=system_u:system_r:system_dbusd_t
tcontext=system_u:system_r:system_dbusd_t tclass=process
Aug 29 18:07:34 dell-studio kernel: [ 23.230831] type=1400
audit(1346256454.447:17): avc: denied { read } for pid=2024
comm="syslog-ng" name="syslog-ng.persist" dev="sda7" ino=73732
scontext=system_u:system_r:syslogd_t
tcontext=system_ubject_r:var_lib_t tclass=file
Aug 29 18:07:34 dell-studio kernel: [ 23.230847] type=1400
audit(1346256454.447:18): avc: denied { open } for pid=2024
comm="syslog-ng" name="syslog-ng.persist" dev="sda7" ino=73732
scontext=system_u:system_r:syslogd_t
tcontext=system_ubject_r:var_lib_t tclass=file
Aug 29 18:07:34 dell-studio kernel: [ 23.230869] type=1400
audit(1346256454.447:19): avc: denied { getattr } for pid=2024
comm="syslog-ng" path="/var/lib/misc/syslog-ng.persist" dev="sda7"
ino=73732 scontext=system_u:system_r:syslogd_t
tcontext=system_ubject_r:var_lib_t tclass=file
Aug 29 18:07:34 dell-studio kernel: [ 23.240312] type=1400
audit(1346256454.457:20): avc: denied { unlink } for pid=2024
comm="syslog-ng" name="syslog-ng.persist" dev="sda7" ino=73732
scontext=system_u:system_r:syslogd_t
tcontext=system_ubject_r:var_lib_t tclass=file
Aug 29 18:07:34 dell-studio kernel: [ 23.593562] type=1400
audit(1346256454.810:21): avc: denied { getattr } for pid=2038
comm="console-kit-dae" path="/run/ConsoleKit" dev="tmpfs" ino=5404
scontext=system_u:system_r:consolekit_t
tcontext=system_ubject_r:initrc_var_run_t tclass=dir
Aug 29 18:07:34 dell-studio kernel: [ 23.593583] type=1400
audit(1346256454.810:22): avc: denied { search } for pid=2038
comm="console-kit-dae" name="ConsoleKit" dev="tmpfs" ino=5404
scontext=system_u:system_r:consolekit_t
tcontext=system_ubject_r:initrc_var_run_t tclass=dir
Aug 29 18:07:34 dell-studio kernel: [ 23.593600] type=1400
audit(1346256454.810:23): avc: denied { write } for pid=2038
comm="console-kit-dae" name="ConsoleKit" dev="tmpfs" ino=5404
scontext=system_u:system_r:consolekit_t
tcontext=system_ubject_r:initrc_var_run_t tclass=dir
Aug 29 18:07:34 dell-studio kernel: [ 23.593608] type=1400
audit(1346256454.810:24): avc: denied { add_name } for pid=2038
comm="console-kit-dae" name="database~"
scontext=system_u:system_r:consolekit_t
tcontext=system_ubject_r:initrc_var_run_t tclass=dir
Aug 29 18:07:40 dell-studio kernel: [ 29.589769] type=1400
audit(1346256460.806:49): avc: denied { read } for pid=2782 comm="sh"
name="meminfo" dev="proc" ino=4026532031
scontext=system_u:system_r:wpa_cli_t tcontext=system_ubject_rroc_t
tclass=file
Aug 29 18:07:40 dell-studio kernel: [ 29.589778] type=1400
audit(1346256460.806:50): avc: denied { open } for pid=2782 comm="sh"
name="meminfo" dev="proc" ino=4026532031
scontext=system_u:system_r:wpa_cli_t tcontext=system_ubject_rroc_t
tclass=file
Aug 29 18:07:40 dell-studio kernel: [ 29.589797] type=1400
audit(1346256460.806:51): avc: denied { getattr } for pid=2782
comm="sh" path="/proc/meminfo" dev="proc" ino=4026532031
scontext=system_u:system_r:wpa_cli_t tcontext=system_ubject_rroc_t
tclass=file
Aug 29 18:07:41 dell-studio kernel: [ 29.823183] type=1400
audit(1346256461.040:52): avc: denied { read write } for pid=2826
comm="ifconfig" path="socket:[5036]" dev="sockfs" ino=5036
scontext=system_u:system_r:ifconfig_t
tcontext=system_u:system_r:wpa_cli_t tclass=unix_dgram_socket
Aug 29 18:07:41 dell-studio kernel: [ 30.120105] type=1400
audit(1346256461.337:53): avc: denied { use } for pid=2955
comm="mount" path="/dev/null" dev="tmpfs" ino=1122
scontext=system_u:system_r:mount_t tcontext=system_u:system_r:wpa_cli_t
tclass=fd
Aug 29 18:07:41 dell-studio kernel: [ 30.120124] type=1400
audit(1346256461.337:54): avc: denied { read write } for pid=2955
comm="mount" path="socket:[5036]" dev="sockfs" ino=5036
scontext=system_u:system_r:mount_t tcontext=system_u:system_r:wpa_cli_t
tclass=unix_dgram_socket
Aug 29 18:09:04 dell-studio kernel: [ 112.791995] type=1400
audit(1346256544.031:56): avc: denied { read } for pid=2038
comm="console-kit-dae" name="machine-id" dev="sda7" ino=184383
scontext=system_u:system_r:consolekit_t
tcontext=system_ubject_r:system_dbusd_var_lib_t tclass=lnk_file
Aug 29 18:09:04 dell-studio kernel: [ 112.875933] type=1400
audit(1346256544.115:57): avc: denied { read } for pid=3066
comm="udev-acl.ck" name="udev-acl" dev="tmpfs" ino=3219
scontext=system_u:system_r:consolekit_t
tcontext=system_ubject_r:udev_var_run_t tclass=dir

After starting xdm:

Aug 29 18:09:34 dell-studio kernel: [ 142.834237] type=1400
audit(1346256574.075:58): avc: denied { read } for pid=3073 comm="rc"
name="profile.env" dev="sda5" ino=663084
scontext=unconfined_u:unconfined_r:run_init_t
tcontext=system_ubject_r:etc_runtime_t tclass=file
Aug 29 18:09:40 dell-studio kernel: [ 149.431140] type=1400
audit(1346256580.672:59): avc: denied { read } for pid=3118
comm="udev-acl.ck" name="udev-acl" dev="tmpfs" ino=3219
scontext=system_u:system_r:consolekit_t
tcontext=system_ubject_r:udev_var_run_t tclass=dir
Aug 29 18:09:46 dell-studio kernel: [ 154.930603] type=1400
audit(1346256586.170:60): avc: denied { read } for pid=3133
comm="udev-acl.ck" name="udev-acl" dev="tmpfs" ino=3219
scontext=system_u:system_r:consolekit_t
tcontext=system_ubject_r:udev_var_run_t tclass=dir

And after the login:

Aug 29 18:10:04 dell-studio kernel: [ 173.755581] type=1400
audit(1346256604.995:65): avc: denied { read } for pid=3140
comm="udev-acl.ck" name="udev-acl" dev="tmpfs" ino=3219
scontext=system_u:system_r:consolekit_t
tcontext=system_ubject_r:udev_var_run_t tclass=dir
Aug 29 18:10:09 dell-studio kernel: [ 177.817507] type=1400
audit(1346256609.057:66): avc: denied { read } for pid=2038
comm="console-kit-dae" name="machine-id" dev="sda7" ino=184383
scontext=system_u:system_r:consolekit_t
tcontext=system_ubject_r:system_dbusd_var_lib_t tclass=lnk_file
Aug 29 18:10:14 dell-studio kernel: [ 182.951425] type=1400
audit(1346256614.192:68): avc: denied { getattr } for pid=3236
comm="udisks-daemon" name="/" dev="sda7" ino=2
scontext=system_u:system_r:devicekit_disk_t
tcontext=system_ubject_r:fs_t tclass=filesystem
Aug 29 18:10:14 dell-studio kernel: [ 183.307019] type=1400
audit(1346256614.546:69): avc: denied { getattr } for pid=3233
comm="pm-is-supported" path="/dev/snapshot" dev="tmpfs" ino=3438
scontext=system_u:system_r:devicekit_power_t
tcontext=system_ubject_r:apm_bios_t tclass=chr_file
Aug 29 18:10:14 dell-studio kernel: [ 183.318766] type=1400
audit(1346256614.558:70): avc: denied { getattr } for pid=3252
comm="pm-is-supported" path="/dev/snapshot" dev="tmpfs" ino=3438
scontext=system_u:system_r:devicekit_power_t
tcontext=system_ubject_r:apm_bios_t tclass=chr_file
Aug 29 18:10:14 dell-studio kernel: [ 183.717762] type=1400
audit(1346256614.957:71): avc: denied { getattr } for pid=3276
comm="pm-powersave" path="/dev/snapshot" dev="tmpfs" ino=3438
scontext=system_u:system_r:devicekit_power_t
tcontext=system_ubject_r:apm_bios_t tclass=chr_file
Aug 29 18:10:14 dell-studio kernel: [ 183.721637] type=1400
audit(1346256614.961:72): avc: denied { write } for pid=3281
comm="mkdir" name="/" dev="tmpfs" ino=1059
scontext=system_u:system_r:devicekit_power_t
tcontext=system_ubject_r:var_run_t tclass=dir
Aug 29 18:10:41 dell-studio kernel: [ 210.642364] type=1400
audit(1346256641.883:73): avc: denied { search } for pid=2129
comm="polkitd" name="ConsoleKit" dev="tmpfs" ino=5404
scontext=system_u:system_r:system_dbusd_t
tcontext=system_ubject_r:consolekit_var_run_t tclass=dir
Aug 29 18:11:55 dell-studio kernel: [ 283.944883] type=1400
audit(1346256715.185:76): avc: denied { read } for pid=3540
comm="udev-acl.ck" name="udev-acl" dev="tmpfs" ino=3219
scontext=system_u:system_r:consolekit_t
tcontext=system_ubject_r:udev_var_run_t tclass=dir
Aug 29 18:12:01 dell-studio kernel: [ 290.394892] type=1400
audit(1346256721.635:77): avc: denied { search } for pid=2129
comm="polkitd" name="ConsoleKit" dev="tmpfs" ino=5404
scontext=system_u:system_r:system_dbusd_t
tcontext=system_ubject_r:consolekit_var_run_t tclass=dir
Aug 29 18:12:06 dell-studio kernel: [ 295.059511] type=1400
audit(1346256726.300:78): avc: denied { read } for pid=3574
comm="udev-acl.ck" name="udev-acl" dev="tmpfs" ino=3219
scontext=system_u:system_r:consolekit_t
tcontext=system_ubject_r:udev_var_run_t tclass=dir
Aug 29 18:20:01 dell-studio kernel: [ 769.954898] type=1400
audit(1346257201.195:80): avc: denied { read open } for pid=6070
comm="sh" name="run-crons" dev="sda5" ino=922129
scontext=system_u:system_r:crond_t tcontext=system_ubject_r:bin_t
tclass=file
Aug 29 18:20:01 dell-studio kernel: [ 769.954945] type=1400
audit(1346257201.195:81): avc: denied { getattr } for pid=6070
comm="sh" path="/usr/sbin/run-crons" dev="sda5" ino=922129
scontext=system_u:system_r:crond_t tcontext=system_ubject_r:bin_t
tclass=file
Aug 29 18:20:01 dell-studio kernel: [ 769.957780] type=1400
audit(1346257201.198:83): avc: denied { read } for pid=6071
comm="sendmail"
path=2F746D702F63726F6E2E637437754B742F63726F6E2E7 26F6F742E36303639202864656C6574656429
dev="sda5" ino=2229458 scontext=system_u:system_r:system_mail_t
tcontext=system_ubject_r:crond_tmp_t tclass=file
Aug 29 18:20:15 dell-studio kernel: [ 784.092973] type=1400
audit(1346257215.333:84): avc: denied { getattr } for pid=3227
comm="upowerd" name="/" dev="sda7" ino=2
scontext=system_u:system_r:devicekit_power_t
tcontext=system_ubject_r:fs_t tclass=filesystem

Thank you again for following me.
Paolo.
 
Old 08-29-2012, 04:48 PM
Sven Vermeulen
 
Default Can't get fully functional (kde) desktop with SELinux

On Wed, Aug 29, 2012 at 06:36:07PM +0200, Paolo Barile wrote:
> > Okay. I'll take a look at the AVCs earlier and draft up a possible fix for
> > you to try out (you can use audit2allow but I'm not sure yet if the result
> > is correct or not).
> Thank you very much.

You're welcome.

> As for your question about error messages, i
> noticed that starting kmix from shell gives me:
>
> QDBusConnection: session D-Bus connection created before
> QCoreApplication. Application may misbehave.
>
> And kmix doesn't start.

Yes. I *think* it is because alsa in the beginning wants to access /dev/shm
(and then create shared memory for interacting with pulseaudio) but because
/dev/shm is mislabeled (in your output, it is device_t, whereas it should be
tmpfs_t) alsa can't do all that. That's probably the cause of this.

See this:

#v+
Aug 21 08:45:49 dell-studio kernel: [ 8.588644] type=1400
audit(1345538718.587:10): avc: denied { write } for pid=1452
comm="alsactl" name="shm" dev="tmpfs" ino=2984
scontext=system_u:system_r:alsa_t tcontext=system_ubject_r:device_t
tclass=dir
Aug 21 08:45:49 dell-studio kernel: [ 8.588652] type=1400
audit(1345538718.587:11): avc: denied { add_name } for pid=1452
comm="alsactl" name="pulse-shm-1979112542"
scontext=system_u:system_r:alsa_t tcontext=system_ubject_r:device_t
tclass=dir
#v-

As you are using cryptsetup, I imagine you are using an initramfs, right? Is
the /dev/shm location mounted in the initramfs or afterwards by openrc?

Is the context corrected later in the boot process (in other words, if you
check the label now with "ls -dZ /dev/shm" is it tmpfs_t now?)

> > following command again, I hope you get enough output?
> >
> > ~# grep root /etc/selinux/*/contexts/files/file_contexts.homedirs
> Oh well, even too much perhaps now! I mean it contains strings like:
>
> /root/.mozilla(/.*)? unconfined_ubject_r:mozilla_home_t

That's correct.

> But I don't know why the root user should have rights for X
> applications. Is that normal? If so, I think we can consider it solved!

Well, the root user for SELinux is just another unconfined user, so it maps
all contexts it knows for users to the root user location.

> Do you suggest to map to unconfined_u the other users too? I'm asking it
> because I noticed a slowness in openening folders (in X) for the first
> time after the login.

They should already be mapped (because of the "__default__" login mapping).
You can verify that using the same grep command as before:

~# grep yourusername /etc/selinux/*/contexts/files/file_contexts.homedirs

> Well thanks to you for the yours!
> Anyway with that module (but the creat_dirs_pattern rule is necessary),
> the /run/console situation is solved too.

Great. Now all I have to do is find out where exactly the creation is done
(to document it properly), but a grep in the sources will probably help me
with that ;-)

[... many denials ...]
> Thank you again for following me.

You're welcome. I'm going over the denials right now one by one and looking
at the ones I think I can resolve and document already. Some of them I skip
and create a bugreport for, like with bug #433177, as I am not certain they
are cosmetic or needed (but some way to track them through a bugreport is
always a good idea imo).

Wkr,
Sven Vermeulen
 
Old 08-29-2012, 06:16 PM
Paolo Barile
 
Default Can't get fully functional (kde) desktop with SELinux

Well I can't check all now since I'm away now, but I can surely say that I don't use an initramfs because I only encrypted the home and swap partitions... Tomorrow I'll check the shm related question.


Paolo.
 
Old 08-29-2012, 06:49 PM
Sven Vermeulen
 
Default Can't get fully functional (kde) desktop with SELinux

On Wed, Aug 29, 2012 at 06:36:07PM +0200, Paolo Barile wrote:
> Aug 29 18:09:04 dell-studio kernel: [ 112.875933] type=1400
> audit(1346256544.115:57): avc: denied { read } for pid=3066
> comm="udev-acl.ck" name="udev-acl" dev="tmpfs" ino=3219
> scontext=system_u:system_r:consolekit_t
> tcontext=system_ubject_r:udev_var_run_t tclass=dir

This one is biting me a bit. Could you try labeling udev-acl.ck (wherever it
is) as udev_exec_t and see if that helps?

The udev-acl.ck code tries to iterate over devices, setting the proper
access controls. This is most likely what is causing your USB disks to not
show up (properly). However, I'm not very fond of allowing consolekit_t to
do this if this is a udev-task (and more specifically, udev-acl.c (the
source cde) uses a lot of udev related methods for this.

The alternative (if we don't run it as udev) is to allow all possible rights
on consolekit, but I think that'll be a lot more than reading the directory
(as this is just the first step).

> Aug 29 18:10:14 dell-studio kernel: [ 183.307019] type=1400
> audit(1346256614.546:69): avc: denied { getattr } for pid=3233
> comm="pm-is-supported" path="/dev/snapshot" dev="tmpfs" ino=3438
> scontext=system_u:system_r:devicekit_power_t
> tcontext=system_ubject_r:apm_bios_t tclass=chr_file
> Aug 29 18:10:14 dell-studio kernel: [ 183.318766] type=1400
> audit(1346256614.558:70): avc: denied { getattr } for pid=3252
> comm="pm-is-supported" path="/dev/snapshot" dev="tmpfs" ino=3438
> scontext=system_u:system_r:devicekit_power_t
> tcontext=system_ubject_r:apm_bios_t tclass=chr_file
> Aug 29 18:10:14 dell-studio kernel: [ 183.717762] type=1400
> audit(1346256614.957:71): avc: denied { getattr } for pid=3276
> comm="pm-powersave" path="/dev/snapshot" dev="tmpfs" ino=3438
> scontext=system_u:system_r:devicekit_power_t
> tcontext=system_ubject_r:apm_bios_t tclass=chr_file
> Aug 29 18:10:14 dell-studio kernel: [ 183.721637] type=1400
> audit(1346256614.961:72): avc: denied { write } for pid=3281
> comm="mkdir" name="/" dev="tmpfs" ino=1059
> scontext=system_u:system_r:devicekit_power_t
> tcontext=system_ubject_r:var_run_t tclass=dir
[...]

This one we need to work out further. I'm okay with allowing
devicekit_power_t to get the attributes of apm_bios_t, but for some reason I
don't think that'll be enough.

Care to add in something like:

#v+
policy_module(localdevicekit, 1.0)

gen_require(`
type devicekit_power_t;
')

dev_getattr_apm_bios_dev(devicekit_power_t)
#v-

and then see what happens next? If it wants to read or write to it, add in:

#v+
dev_rw_apm_bios(devicekit_power_t)
#v-

For the rest, I've put in quite a few changes in the policy for the other
denials shown earlier. They will definitely be in revision 5, but if you
know how to work with live ebuilds, you can use the SELinux live ebuilds as
well (since the changes are in the policy repository).

An overview of all changes:
http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-refpolicy.git;a=summary

Wkr,
Sven Vermeulen
 
Old 08-30-2012, 06:22 PM
Paolo Barile
 
Default Can't get fully functional (kde) desktop with SELinux

On 29/08/2012 20:49, Sven Vermeulen wrote:
> Is the context corrected later in the boot process (in other words, if you
> check the label now with "ls -dZ /dev/shm" is it tmpfs_t now?)
Well in fact /dev/shm was mislabeled even if I don't use initramfs, so I
added the following to fstab:

shm /dev/shm tmpfs
rw,rootcontext=system_ubject_r:tmpfs_t,seclabel, nosuid,nodev,noexec,relatime
0 0

So now (after reboot) it is labeled: system_ubject_r:tmpfs_t /dev/shm.

Anyway alsactl (and kmix) still doesn't work. It is (I think) because
there's something strange in denials:

Aug 30 19:52:15 dell-studio kernel: [ 8.562950] type=1400
audit(1346356301.561:3): avc: denied { getattr } for pid=1461
comm="alsactl" name="/" dev="tmpfs" ino=1232
scontext=system_u:system_r:alsa_t tcontext=system_ubject_r:tmpfs_t
tclass=filesystem
Aug 30 19:52:15 dell-studio kernel: [ 8.562975] type=1400
audit(1346356301.561:5): avc: denied { write } for pid=1461
comm="alsactl" name="shm" dev="tmpfs" ino=1236
scontext=system_u:system_r:alsa_t tcontext=system_ubject_r:device_t
tclass=dir
Aug 30 19:52:15 dell-studio kernel: [ 8.562984] type=1400
audit(1346356301.561:6): avc: denied { add_name } for pid=1461
comm="alsactl" name="pulse-shm-3830975079"
scontext=system_u:system_r:alsa_t tcontext=system_ubject_r:device_t
tclass=dir
Aug 30 19:52:15 dell-studio kernel: [ 8.563014] type=1400
audit(1346356301.561:7): avc: denied { create } for pid=1461
comm="alsactl" name="pulse-shm-3830975079"
scontext=system_u:system_r:alsa_t tcontext=system_ubject_r:device_t
tclass=file
Aug 30 19:52:15 dell-studio kernel: [ 8.563027] type=1400
audit(1346356301.562:8): avc: denied { read write open } for pid=1461
comm="alsactl" name="pulse-shm-3830975079" dev="tmpfs" ino=4239
scontext=system_u:system_r:alsa_t tcontext=system_ubject_r:device_t
tclass=file
Aug 30 19:52:15 dell-studio kernel: [ 8.608145] type=1400
audit(1346356301.607:9): avc: denied { remove_name } for pid=1461
comm="alsactl" name="pulse-shm-3830975079" dev="tmpfs" ino=4239
scontext=system_u:system_r:alsa_t tcontext=system_ubject_r:device_t
tclass=dir
Aug 30 19:52:15 dell-studio kernel: [ 8.608154] type=1400
audit(1346356301.607:10): avc: denied { unlink } for pid=1461
comm="alsactl" name="pulse-shm-3830975079" dev="tmpfs" ino=4239
scontext=system_u:system_r:alsa_t tcontext=system_ubject_r:device_t
tclass=file

As you can see even if the first denial reports shm labeled as tmpfs_t
all the other report it as device_it. How can it be possible?


> On Wed, Aug 29, 2012 at 06:36:07PM +0200, Paolo Barile wrote:
>> Aug 29 18:09:04 dell-studio kernel: [ 112.875933] type=1400
>> audit(1346256544.115:57): avc: denied { read } for pid=3066
>> comm="udev-acl.ck" name="udev-acl" dev="tmpfs" ino=3219
>> scontext=system_u:system_r:consolekit_t
>> tcontext=system_ubject_r:udev_var_run_t tclass=dir
> This one is biting me a bit. Could you try labeling udev-acl.ck (wherever it
> is) as udev_exec_t and see if that helps?
>
> The udev-acl.ck code tries to iterate over devices, setting the proper
> access controls. This is most likely what is causing your USB disks to not
> show up (properly). However, I'm not very fond of allowing consolekit_t to
> do this if this is a udev-task (and more specifically, udev-acl.c (the
> source cde) uses a lot of udev related methods for this.
>
> The alternative (if we don't run it as udev) is to allow all possible rights
> on consolekit, but I think that'll be a lot more than reading the directory
> (as this is just the first step).
The file is /usr/lib64/ConsoleKit/run-seat.d/udev-acl.ck, it is a
symlink to /usr/libexec/udev-acl that is labeled bin_t.
Anyway I relabeled udev-acl.ck as udev_exec_t, so that denial
disappeard, but now I have this new one:

Aug 30 19:31:06 dell-studio kernel: [ 75.419082] type=1400
audit(1346347866.859:59): avc: denied { read } for pid=3121
comm="console-kit-dae" name="udev-acl.ck" dev="sda5" ino=1057310
scontext=system_u:system_r:consolekit_t
tcontext=system_ubject_r:udev_exec_t tclass=lnk_file


>> Aug 29 18:10:14 dell-studio kernel: [ 183.307019] type=1400
>> audit(1346256614.546:69): avc: denied { getattr } for pid=3233
>> comm="pm-is-supported" path="/dev/snapshot" dev="tmpfs" ino=3438
>> scontext=system_u:system_r:devicekit_power_t
>> tcontext=system_ubject_r:apm_bios_t tclass=chr_file
>> Aug 29 18:10:14 dell-studio kernel: [ 183.318766] type=1400
>> audit(1346256614.558:70): avc: denied { getattr } for pid=3252
>> comm="pm-is-supported" path="/dev/snapshot" dev="tmpfs" ino=3438
>> scontext=system_u:system_r:devicekit_power_t
>> tcontext=system_ubject_r:apm_bios_t tclass=chr_file
>> Aug 29 18:10:14 dell-studio kernel: [ 183.717762] type=1400
>> audit(1346256614.957:71): avc: denied { getattr } for pid=3276
>> comm="pm-powersave" path="/dev/snapshot" dev="tmpfs" ino=3438
>> scontext=system_u:system_r:devicekit_power_t
>> tcontext=system_ubject_r:apm_bios_t tclass=chr_file
>> Aug 29 18:10:14 dell-studio kernel: [ 183.721637] type=1400
>> audit(1346256614.961:72): avc: denied { write } for pid=3281
>> comm="mkdir" name="/" dev="tmpfs" ino=1059
>> scontext=system_u:system_r:devicekit_power_t
>> tcontext=system_ubject_r:var_run_t tclass=dir
> [...]
>
> This one we need to work out further. I'm okay with allowing
> devicekit_power_t to get the attributes of apm_bios_t, but for some reason I
> don't think that'll be enough.
>
> Care to add in something like:
>
> #v+
> policy_module(localdevicekit, 1.0)
>
> gen_require(`
> type devicekit_power_t;
> ')
>
> dev_getattr_apm_bios_dev(devicekit_power_t)
> #v-
>
> and then see what happens next? If it wants to read or write to it, add in:
>
> #v+
> dev_rw_apm_bios(devicekit_power_t)
> #v-
Ok with this module the denial about devicekit_power_t over apm_bios has
gone. It seems that the rw rights are not necessary.
Now it only remains the last one:

Aug 30 19:53:13 dell-studio kernel: [ 98.792934] type=1400
audit(1346349193.267:60): avc: denied { write } for pid=3240
comm="mkdir" name="/" dev="tmpfs" ino=2982
scontext=system_u:system_r:devicekit_power_t
tcontext=system_ubject_r:var_run_t tclass=dir

But even if it is related to devicekit_power_t it isn't over apm_bios,
but over var_run_t. Should I try to add something similar (but to
var_run_t) in that module?
>
> For the rest, I've put in quite a few changes in the policy for the other
> denials shown earlier. They will definitely be in revision 5, but if you
> know how to work with live ebuilds, you can use the SELinux live ebuilds as
> well (since the changes are in the policy repository).
>
> An overview of all changes:
> http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-refpolicy.git;a=summary
>
> Wkr,
> Sven Vermeulen
>

Ok, tomorrow I'll try the live ebuilds and I'll let you know. Pure
curiosity: when I'll try the live ebuild or when the rev5 will be out,
should I remove these modules you wrote in emails (localconsolekit and
localdevicekit)?
Thank you.
Paolo.
 
Old 08-31-2012, 05:23 PM
Paolo Barile
 
Default Can't get fully functional (kde) desktop with SELinux

I tried the live ebuilds and something changed, but the problems didn't
go away.
Except the every present alsactl denials I have these related to cryptsetup:

Aug 31 17:48:56 dell-studio kernel: [ 10.300271] type=1400
audit(1346428122.197:11): avc: denied { getattr } for pid=1540
comm="cryptsetup" name="/" dev="tmpfs" ino=1149
scontext=system_u:system_r:lvm_t tcontext=system_ubject_r:tmpfs_t
tclass=filesystem
Aug 31 17:48:56 dell-studio kernel: [ 10.315780] type=1400
audit(1346428122.212:12): avc: denied { read } for pid=1540
comm="cryptsetup" name="queue.bin" dev="tmpfs" ino=1876
scontext=system_u:system_r:lvm_t
tcontext=system_ubject_r:udev_var_run_t tclass=file

The following for syslog-ng:

Aug 31 17:48:56 dell-studio kernel: [ 23.588852] type=1400
audit(1346428135.485:15): avc: denied { read } for pid=2013
comm="syslog-ng" name="syslog-ng.persist" dev="sda7" ino=73729
scontext=system_u:system_r:syslogd_t
tcontext=system_ubject_r:var_lib_t tclass=file
Aug 31 17:48:56 dell-studio kernel: [ 23.588861] type=1400
audit(1346428135.485:16): avc: denied { open } for pid=2013
comm="syslog-ng" name="syslog-ng.persist" dev="sda7" ino=73729
scontext=system_u:system_r:syslogd_t
tcontext=system_ubject_r:var_lib_t tclass=file
Aug 31 17:48:56 dell-studio kernel: [ 23.588878] type=1400
audit(1346428135.485:17): avc: denied { getattr } for pid=2013
comm="syslog-ng" path="/var/lib/misc/syslog-ng.persist" dev="sda7"
ino=73729 scontext=system_u:system_r:syslogd_t
tcontext=system_ubject_r:var_lib_t tclass=file
Aug 31 17:48:56 dell-studio kernel: [ 23.597238] type=1400
audit(1346428135.494:18): avc: denied { unlink } for pid=2013
comm="syslog-ng" name="syslog-ng.persist" dev="sda7" ino=73729
scontext=system_u:system_r:syslogd_t
tcontext=system_ubject_r:var_lib_t tclass=file


Again consolekit with policykit:

Aug 31 17:48:56 dell-studio kernel: [ 23.872708] type=1400
audit(1346428135.769:19): avc: denied { read } for pid=2101
comm="console-kit-dae" name="udev-acl.ck" dev="sda5" ino=1057310
scontext=system_u:system_r:consolekit_t
tcontext=system_ubject_r:udev_exec_t tclass=lnk_file
Aug 31 17:48:56 dell-studio kernel: [ 24.322689] type=1400
audit(1346428136.219:24): avc: denied { execute_no_trans } for
pid=2119 comm="dbus-daemon-lau" path="/usr/libexec/polkitd" dev="sda5"
ino=922900 scontext=system_u:system_r:system_dbusd_t
tcontext=system_ubject_rolicykit_exec_t tclass=file
Aug 31 17:50:21 dell-studio kernel: [ 110.007624] type=1400
audit(1346428221.949:50): avc: denied { search } for pid=2119
comm="polkitd" name="ConsoleKit" dev="tmpfs" ino=4520
scontext=system_u:system_r:system_dbusd_t
tcontext=system_ubject_r:consolekit_var_run_t tclass=dir
Aug 31 17:51:41 dell-studio kernel: [ 189.862655] type=1400
audit(1346428301.804:52): avc: denied { search } for pid=2119
comm="polkitd" name="ConsoleKit" dev="tmpfs" ino=4520
scontext=system_u:system_r:system_dbusd_t
tcontext=system_ubject_r:consolekit_var_run_t tclass=dir


Dbus:

Aug 31 17:48:56 dell-studio kernel: [ 24.322653] type=1400
audit(1346428136.219:23): avc: denied { read open } for pid=2119
comm="dbus-daemon-lau" name="polkitd" dev="sda5" ino=922900
scontext=system_u:system_r:system_dbusd_t
tcontext=system_ubject_rolicykit_exec_t tclass=file
Aug 31 17:48:56 dell-studio kernel: [ 24.322689] type=1400
audit(1346428136.219:24): avc: denied { execute_no_trans } for
pid=2119 comm="dbus-daemon-lau" path="/usr/libexec/polkitd" dev="sda5"
ino=922900 scontext=system_u:system_r:system_dbusd_t
tcontext=system_ubject_rolicykit_exec_t tclass=file

Devicekit:

Aug 31 17:49:54 dell-studio kernel: [ 82.473330] type=1400
audit(1346428194.371:44): avc: denied { getattr } for pid=3187
comm="udisks-daemon" name="/" dev="sda7" ino=2
scontext=system_u:system_r:devicekit_disk_t
tcontext=system_ubject_r:fs_t tclass=filesystem
Aug 31 17:49:55 dell-studio kernel: [ 83.242850] type=1400
audit(1346428195.140:45): avc: denied { write } for pid=3232
comm="mkdir" name="/" dev="tmpfs" ino=1115
scontext=system_u:system_r:devicekit_power_t
tcontext=system_ubject_r:var_run_t tclass=dir
Aug 31 17:59:55 dell-studio kernel: [ 683.103378] type=1400
audit(1346428795.045:56): avc: denied { getattr } for pid=3178
comm="upowerd" name="/" dev="sda7" ino=2
scontext=system_u:system_r:devicekit_power_t
tcontext=system_ubject_r:fs_t tclass=filesystem


Cron:

Aug 31 17:48:56 dell-studio kernel: [ 23.951130] type=1400
audit(1346428135.848:20): avc: denied { read } for pid=2102
comm="crond" name="root" dev="sda7" ino=12796
scontext=system_u:system_r:crond_t tcontext=system_ubject_r:file_t
tclass=file
Aug 31 17:48:56 dell-studio kernel: [ 23.951145] type=1400
audit(1346428135.848:21): avc: denied { open } for pid=2102
comm="crond" name="root" dev="sda7" ino=12796
scontext=system_u:system_r:crond_t tcontext=system_ubject_r:file_t
tclass=file
Aug 31 17:48:56 dell-studio kernel: [ 23.951170] type=1400
audit(1346428135.848:22): avc: denied { getattr } for pid=2102
comm="crond" path="/var/spool/cron/crontabs/root" dev="sda7" ino=12796
scontext=system_u:system_r:crond_t tcontext=system_ubject_r:file_t
tclass=file
Aug 31 17:50:01 dell-studio kernel: [ 89.975499] type=1400
audit(1346428201.873:46): avc: denied { read open } for pid=3248
comm="sh" name="run-crons" dev="sda5" ino=922129
scontext=system_u:system_r:crond_t tcontext=system_ubject_r:bin_t
tclass=file
Aug 31 17:50:01 dell-studio kernel: [ 89.975545] type=1400
audit(1346428201.873:47): avc: denied { getattr } for pid=3248
comm="sh" path="/usr/sbin/run-crons" dev="sda5" ino=922129
scontext=system_u:system_r:crond_t tcontext=system_ubject_r:bin_t
tclass=file
Aug 31 17:50:01 dell-studio kernel: [ 90.006658] type=1400
audit(1346428201.905:49): avc: denied { read } for pid=3249
comm="sendmail"
path=2F746D702F63726F6E2E6F384F6E336F2F63726F6E2E7 26F6F742E33323437202864656C6574656429
dev="sda5" ino=2229313 scontext=system_u:system_r:system_mail_t
tcontext=system_ubject_r:crond_tmp_t tclass=file
Aug 31 17:59:01 dell-studio kernel: [ 629.136631] type=1400
audit(1346428741.078:53): avc: denied { getattr } for pid=5838
comm="sh" path="/bin/rm" dev="sda5" ino=1700617
scontext=system_u:system_r:crond_t tcontext=system_ubject_r:bin_t
tclass=file

Thank you.
Paolo.
 

Thread Tools




All times are GMT. The time now is 10:07 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org