SELinux and Shorewall with IPSets

[Dominick Grift]

On 06/30/2010 06:12 PM, Mr Dash Four wrote:
> 
>>>> For example if ssh bind tcp sockets to port 11000:
>>>>
>>>> sudo semanage port -a -t ssh_port_t -p tcp 11000
>>>>         
>>> Is this type "ssh_port_t" something, which is already registered (as
>>> part of the targeted policy perhaps?) and I am just modifying it or
>>> is this not the case?
>>>
>>>     
>>
>> Yes ssh_port_t is the ssh port type. tcp;22 is labelled with type
>> ssh_port_t, we just label tcp:11000 ssh_port_t so that ssh can bind tcp
>> sockets to that port as well.
>>   
> Well, I do not wish to keep the tcp/22 as part of the policy (if left,
> it creates a loophole!). I tried "semanage port -m -t ssh_port_t -p tcp
> 222" (to modify it), but got "/usr/sbin/semanage: Port tcp/222 is not
> defined". I then added tcp/222 as you suggested and then tried to
> execute "semanage port -d -t ssh_port_t -p tcp 22" to remove the tcp/22
> part, but got this: "/usr/sbin/semanage: Port tcp/22 is defined in
> policy, cannot be deleted". What does that mean exactly?

It means that the corenetwork module (which is compiled into the base
module) has a port object context specification for type ssh_port_t --
tcp:22

So you would have edit that in the main selinux-policy package.

> 
>>>>> using a directory, which maps to a non-standard directory (through
>>>>> symbolic link - /var/log is a symbolic link to a different/secure
>>>>> partition of the disk) and that also causes "denied { read }" with
>>>>> "tclass=lnk_file" alert.
>>>>>             
>>>> This will require a patch (need more info : avc denials of this event)
>>>>         
>>> I will post it separately as when I run the image with qemu cutting
>>> and pasting is not as straightforward.
>>>     
> type=1400 audit(1277908958.656.4): avc: denied  { read } for pid=906
> comm="rsyslogd" name="log" dev=dm-0 ino=16386
> scontext=system_u:system_r:syslogd_t:s0
> tcontext=unconfined_u:object_r:var_t:s0 tclass=lnk_file
> 
> There is a similar one with "mingetty" as well, but
> scontext=system_u:system_r:getty_t:s0

This symlink is mislabeled. What/who created it? if you , yourself
created it, then you may be able to make things work by labeling the
symlink type bin_t or type var_log_t, provided that the source of the
interaction (in this case syslogd_t and getty_t) have access to the
target of the symlink.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/selinux/attachments/20100630/1625279d/attachment.bin