Re: [gentoo-hardened] SELinux - network streams

With a deeper search in the documentation,
I started to watch the uncorrect labelled daemons (initrc_t type)
And here is a few response :

In the existing /etc/security/selinux/file_contexts file, I found  
uncorrect labelling definitions for the courier-imap package.

So, I put here a few suggestion about this ... as I do not know  
weither I should tell this here or on bugzilla (is it really a bug ? )


## new entry
/usr/lib(64)?/courier/courier-authlib/*  
system_u:object_r:courier_authdaemon_exec_t
# chcon -t courier_authdaemon_exec_t /usr/lib/courier/courier-authlib/*

## new entry
/usr/lib/courier-imap/*  system_u:object_r:courier_exec_t
# chcon -t courier_exec_t /usr/lib/courier-imap/*


(/usr/bin/imapd  --      system_u:object_r:courier_pop_exec_t)
## newentry
/usr/sbin/courier-imapd system_u:object_r:courier_pop_exec_t
/usr/sbin/courier-pop3d system_u:object_r:courier_pop_exec_t
# chcon -t courier_pop_exec_t /usr/sbin/courier-imapd
# chcon -t courier_pop_exec_t /usr/sbin/courier-pop3d

(/usr/lib(64)?/courier/courier/imaplogin --  
system_u:object_r:courier_pop_exec_t)
## new entry
/usr/sbin/imaplogin system_u:object_r:courier_pop_exec_t
# chcon -t courier_pop_exec_t /usr/sbin/imaplogin

## new entry
/usr/sbin/couriertcpd   --      system_u:object_r:courier_tcpd_exec_t
# chcon -t courier_tcpd_exec_t couriertcpd

## new entry
/usr/sbin/courierlogger --      system_u:object_r:courier_exec_t
# chcon -t courier_exec_t /usr/sbin/courierlogger

For the following information of the file_contexts file, I did not  
find anything in courier-imap
-----
/usr/lib(64)?/courier/courier/courierpop.*      --       
system_u:object_r:courier_pop_exec_t
/usr/lib(64)?/courier/imapd     --      system_u:object_r:courier_pop_exec_t
/usr/lib(64)?/courier/pop3d     --      system_u:object_r:courier_pop_exec_t


---
At the end, here is the result I got.
Most of the daemon are correctly labelled, though courierlogger is  
still angry (why? initrc_t and also why courier_tcpd_t though I  
indicated courier_exec_t !) :D

ps -eZ | grep cour

system_u:system_r:initrc_t       4551 ?        00:00:00 courierlogger
system_u:system_r:courier_authdaemon_t 4552 ?  00:00:00 authdaemond
system_u:system_r:courier_authdaemon_t 4556 ?  00:00:00 authdaemond
system_u:system_r:courier_authdaemon_t 4557 ?  00:00:00 authdaemond
system_u:system_r:courier_authdaemon_t 4558 ?  00:00:00 authdaemond
system_u:system_r:courier_authdaemon_t 4559 ?  00:00:00 authdaemond
system_u:system_r:courier_authdaemon_t 4560 ?  00:00:00 authdaemond
system_u:system_r:courier_tcpd_t 4625 ?        00:00:00 couriertcpd
system_u:system_r:courier_tcpd_t 4627 ?        00:00:00 courierlogger


I will btw post it on bugzilla when  this will be over.

Julien Thomas.

julien.thomas@×××××××××××××.fr a écrit :

> In fact, I think that there is no problem with protmap as I got
> mv1 sbin # ls -lZ port*
> -rwxr-xr-x  root root system_u:object_r:portmap_exec_t portmap
>
> However, other binaries such as rpc.* or other are labelled as bin_t
> which is not correct, I think.
>
> But as I work with managed SELinux (2006+), I do not have the src
> directories and thus policy/ subdirectories ... So I'm quite blocked
> here :
> my filesystem is not correctly labelled and I cannot find which labels
> I should have !
>
> Is there a way to get these information ?
>
> Chris PeBenito <pebenito@g.o> a écrit :
>
>> On Wed, 2007-08-01 at 11:53 +0200, julien.thomas@×××××××××××××.fr wrote:
>>> Thanks for the tip with ssh. This work really well now.
>>>
>>> Unefortunately, it is not the only error I got with SELinux.
>>> Some files were not correctly labelled (though I don't know how many
>>> rlpkg -ar were done ...)
>>>
>>> For example here is a result of audit2allow. But the most important
>>> problem, I think, is the networks error with for example allow
>>> kernel_t lo_node_t:node udp_recv.
>>>
>>> For a full example, I have added the kernel messages
>>> (/var/log/kern.log | grep portmap) produced by the portmap daemon. I
>>> think that it s a recurrent error that is not produced by the daemon
>>> but more by a network/kernel wrong labelling/policy.
>>>
>>> If someone has any clue about this, I will take it as I cannot find
>>> any relevant information on the web.
>>
>> At a minimum, the portmap service is running in the wrong domain:
>>
>>> allow initrc_t inaddr_any_node_t:tcp_socket node_bind;
>>> allow initrc_t pop_port_t:tcp_socket name_bind;
>>> allow initrc_t unspec_node_t:tcp_socket node_bind;
>>> allow initrc_t var_lib_t:sock_file { create rename setattr unlink };
>>
>> --
>> Chris PeBenito
>> <pebenito@g.o>
>> Developer,
>> Hardened Gentoo Linux
>>
>> Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE6AF9243
>> Key fingerprint = B0E6 877A 883F A57A 8E6A  CB00 BC8E E42D E6AF 9243
>>
>
>
>
> --
> gentoo-hardened@g.o mailing list



-- 
gentoo-hardened@g.o mailing list