[gentoo-hardened] SELinux - courier-imap

Hi.
The problems of courier-imap began to be solved ...

(The previous post where labelled by "SELinux - network streams" but  
as I am more focused with courier-imap now, I though it was good to  
change the subject)

However, here is the problem I have with file labelling :

I put it /etc/security/selinx/file_contexts the following lines
/var/run/impad.*  system_u:object_r:courier_var_run_t
/var/run/pop3.*  system_u:object_r:courier_var_run_t
/var/run/authdaemon.*  system_u:object_r:courier_var_run_t

as the previous ones (/var/run/courier(/.*)?) where wrong.

However, restorecon do not give the good contexts for these files
(var_run_t). Besides, when the server are restarted or after let's say  
one hour,
the files got the var_run_t context though I changed them with chcon.

Where should I put this file_context information.
(Do I have to add this I a QuickFix module ?)

for the other problem, It was due to transition problems.
I have added the following lines :
type_transition initrc_t courier_exec_t:process courier_tcpd_t;
type_transition courier_tcpd_t courier_authdaemon_exec_t:process  
courier_authdaemon_t;

Julien Thomas.

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

> Chris PeBenito <pebenito@g.o> a écrit :
>
>> On Thu, 2007-08-02 at 11:59 +0200, julien.thomas@×××××××××××××.fr wrote:
>>> 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 ? )
>>
>> Yes, it is a bug.  I guess some courier files have moved.
>>
>>> ## 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_tcpd_t 4627 ?        00:00:00 courierlogger
>>
>> There already is a courierlogger in a courier domain; perhaps the top
>> one is a stale courierlogger that wasn't killed when you restarted
>> courier?
>>
> In fact, I have restarted the server several times as it was required
> and I still have this problem.
>
> when the courier-imap process is started, everything is working (and
> thus here are the courierlogger processes in the good domain)
>
> but when courier-authlib is  started, another courierlogger is launched
> in the initrc domain, as written in th rc file
>
> start() {
>         checkconfig || return 1
>         setauth
>         ebegin "Starting courier-authlib: ${AUTHDAEMOND}"
>         start-stop-daemon --quiet --start --pidfile "${pidfile}" --exec \
>                 /usr/bin/env ${logger} -- ${LOGGEROPTS}
> -pid="${pidfile}" -start "${AUTHLIB}/${AUTHDAEMOND}"
>         eend $?
> }
>
> so, why is courierlogger launched in the initrc domain while
> authdaemon, launched in the same script, are in the correct domain ?
> For courrier-imap, the scripts command are rather different so no
> comparison are possible ...
>
> Julien Thomas
>
>> --
>> 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