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.