Hello,
Although innd.te is the usual example of policy, i still can't get it start right from the init-script. (Fedora Core 2, policy-sources-1.11.3-3). The problem is near the 'su', IMHO. Namely, when innd runs from script as
su -s /bin/bash - news -c /etc/rc.news
it obtains context user_u:user_r:user_t and no domain_auto_trans together with default_contexts tuning could resolve it, until i've added the new user:
user news roles system_r;
After that the context of innd became user_u:system_r:innd_t (not news:system_r:innd_t, as i hoped, but anyway...)
Besides, the same problem in other place occured to be more persistent: regular cron job running nntpsend leads to the following (permissive mode):
avc: denied { transition } for pid=24801 exe=/bin/su path=/bin/bash dev=sda1 ino=895926 scontext=system_u:system_r:system_crond_su_t tcontext=user_u:sysadm_r:sysadm_t tclass=process avc: denied { siginh } for pid=24801 exe=/bin/bash scontext=system_u:system_r:system_crond_su_t tcontext=user_u:sysadm_r:sysadm_t tclass=process (same for 'rlimitinh' and 'noatsecure').
This caused by su - news -c "unset LANG; unset LC_COLLATE; /usr/lib/news/bin/nntpsend"
I've tried to force the domain_auto_trans to initrc_t etc, also added corresponding records to default_contexts
system_r:system_crond_su_t system_r:initrc_t
but without any effect! (And no conflicts with other policy rules, as far as i could see).
I'm eager to get any help on this, please.
Also, i'd like to ask the reason of why some file type transitions doesn't work on sockets. E.g., when winbindd (runs in smbd_t) creates the socket in the directory of samba_var_t type and clients try to use it, the log file are full of deny { connectto } unix_stream_socket with smbd_t in tcontext. At the same time the /path/to/socket/file has correct samba_var_t type. The situation doesn't change if i write file_type_auto_trans(smbd_t, samba_var_t, samba_var_t, sock_file)
The unix domain socket still has smbd_t, not samba_var_t, when someone tries to 'connectto'. Same situation with some other sockets of different domains. Is it the possible to change this behavior, or unix domain socket always has the type of creating process ?
On Tue, 2004-12-28 at 14:43, Oleg Museyko wrote:
Although innd.te is the usual example of policy, i still can't get it start right from the init-script.
The example was likely written up pre-Fedora, and having 'su' change the security context (via pam_selinux) was introduced by Fedora.
(Fedora Core 2, policy-sources-1.11.3-3). The problem is near the 'su', IMHO. Namely, when innd runs from script as
su -s /bin/bash - news -c /etc/rc.news
In FC3, this has been addressed by introducing a separate 'runuser' program, I believe. Using su in this manner isn't a good idea even without SELinux in the picture.
This caused by su - news -c "unset LANG; unset LC_COLLATE; /usr/lib/news/bin/nntpsend"
Likewise, using 'su' in this manner considered harmful.
Also, i'd like to ask the reason of why some file type transitions doesn't work on sockets. E.g., when winbindd (runs in smbd_t) creates the socket in the directory of samba_var_t type and clients try to use it, the log file are full of deny { connectto } unix_stream_socket with smbd_t in tcontext. At the same time the /path/to/socket/file has correct samba_var_t type. The situation doesn't change if i write file_type_auto_trans(smbd_t, samba_var_t, samba_var_t, sock_file)
A Unix domain socket has two separate but related objects: the socket itself and the file by which it is named. They are separate objects with separate permission checks applied. The socket is labeled based on the creating process and the connectto permission check lets you establish a direct relationship between the peers. The file is labeled in accordance with the usual file typing rules, and the normal file write check is applied to it. The can_unix_connect() macro is typically used to grant the peer-to-peer permission.
On Tue, 2004-12-28 at 14:43, Oleg Museyko wrote:
Although innd.te is the usual example of policy, i still can't get it start right from the init-script. (Fedora Core 2, policy-sources-1.11.3-3).
BTW, upgrading to FC 3 is strongly recommended for SELinux users, both due to improved integration of SELinux in FC 3 and due to compatibility problems that have crept into FC 2 from kernel updates without corresponding policy updates.
selinux@lists.fedoraproject.org