On 01/05/2011 08:48 AM, Christopher J. PeBenito wrote:
> On 12/16/10 12:32, Paul Nuzzi wrote:
>> On 12/15/2010 03:54 PM, Christopher J. PeBenito wrote:
>>> On 12/10/10 18:22, Paul Nuzzi wrote:
>>>> Added labeled IPSec support to hadoop. SELinux will be able to enforce what services are allowed to
>>>> connect to. Labeled IPSec can enforce the range of services they can receive from. This enforces
>>>> the architecture of Hadoop without having to modify any of the code. This adds a level of
>>>> confidentiality, integrity, and authentication provided outside the software stack.
>>>
>>> A few things.
>>>
>>> The verb used in Reference Policy interfaces for peer recv is recvfrom
>>> (a holdover from previous labeled networking implementations). So the
>>> interfaces are like hadoop_recvfrom_datanode().
>>
>> Easy change.
>>
>>> It seems like setkey should be able to setcontext any type used on ipsec
>>> associations. I think the best thing would be to add additional support
>>> to either the ipsec or corenetwork modules (I haven't decided which one
>>> yet) for associations. So, say we have an interface called
>>> ipsec_spd_type() which adds the parameter type to the attribute
>>> ipsec_spd_types. Then we can have an allow setkey_t
>>> ipsec_spd_types:association setkey; rule and we don't have to update it
>>> every time more labeled network is added.
>>
>> That seems a lot less clunky than updating setkey every time we add a new association.
>>
>>> This is definitely wrong since its not a file:
>>> +files_type(hadoop_lan_t)
>>
>> Let me know how you would like to handle associations and I could update the
>> patch.
>
> Lets go with putting the associations in corenetwork.
>
>> Will the files_type error be cleared up when we re-engineer this?
>
> I'm not sure what you mean. The incorrect rule was added in your patch.
>
Adds labeled IPSec policy to hadoop to control the remote processes that are allowed to connect to the cloud's services.
Signed-off-by: Paul Nuzzi <pjnuzzi@tycho.ncsc.mil>
Make the mount domain able to request kernel to load a kernel module.
Otherwise the binfmt_misc kernel module won't be properly loaded
during system booting up.
type=1400 audit(1292850971.104:4): avc: denied { module_request } for pid=87 comm="mount" kmod="devtmpfs" scontext=system_u:system_r:mount_t:s0-s15:c0.c1023 tcontext=system_u:system_r:kernel_t:s15:c0.c1023 tclass=system
type=1400 audit(1292851024.844:13): avc: denied { module_request } for pid=409 comm="mount" kmod="binfmt_misc" scontext=system_u:system_r:mount_t:s0-s15:c0.c1023 tcontext=system_u:system_r:kernel_t:s15:c0.c1023 tclass=system
Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
The login or ssh program will relabel a tty or pty device after users
log in, and the vlock domain would only need to use the relabeled tty
or pty device, rather than the whole ttynode or ptynode attribute.
Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
On 12/15/2010 03:17 PM, Christopher J. PeBenito wrote:
> On 12/13/10 10:39, Paul Nuzzi wrote:
>> On 12/11/2010 04:01 AM, Dominick Grift wrote:
>> On 12/11/2010 12:22 AM, Paul Nuzzi wrote:
>>
>> Does hadoop depend on kerberos? If no then kerberos_use should probably
>> be optional.
>>
>>
>>> The new version of hadoop added Kerberos for authentication.
>
> So, to be explicit, its an unconditional requirement?
Yes. I think all future versions of hadoop will be kerberos enabled.
> It seems like there should be a hadoop_home_t that is
> userdom_user_home_content()
Updated.
Signed-off-by: Paul Nuzzi <pjnuzzi@tycho.ncsc.mil>
The attached patch adds sepgsql_contexts file into appconfig-*
directory. This configuration is used to initial labeling on
installation time for each database objects.
We can easily look up an appropriate label using selabel_loopup(3)
APIs. The 'sepgsql_contexts' is default for SE-PostgreSQL.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
Current policy sets /lib(32|64)?/rc/init.d to lib_t. This causes
problems for DHCP among other things, as the initrc domain does not
have permissions to perform some operations. Changing to
initrc_state_t (the labeling used for /var/lib/init.d by
the older baselayout-1) resolves some of these issues.
Signed-off-by: Chris Richards <gizmo@giz-works.com>
* Rearrange rules in the template.
* Remove samhain_etc_t:dir perms since there are no such dirs.
* Add extra docs in samhain_domtrans().
* Include samhaind_t in admin interface process perms.
Note, extra privileges may need to be granted to the samhain domain
if its default configuration file(/etc/samhainrc) is changed.
The samhain program could be used in the following way:
(In secadm_r role)
1. Initialize filesystem signature database:
newrole -l s15:c0.c1023 -p -- -c "samhain -t init"
(Note, the current secadm console will be blocked until
the database is completed)
2. Start samhain deamon to check filesystem integrity
newrole -l s15:c0.c1023 -p -- -c "samhain -t check -D"
3. Update filesystem signature database:
newrole -l s15:c0.c1023 -p -- -c "samhain -t update"
(In sysadm_r role)
1. Start samhain in daemon mode:
run_init /etc/init.d/samhain start
2. Stop samhain daemon:
run_init /etc/init.d/samhain stop
3. Check samhain daemon status:
run_init /etc/init.d/samhain status
4. Read/write samhain log files:
newrole -l s15:c0.c1023 -p -- -c "cat /var/log/samhain_log"
5. Remove samhain database files
newrole -l s15:c0.c1023 -p -- -c "rm /var/lib/samhain/samhain_file"
Note:
1. Stop samhain daemon before updating signature database.
2. Don't try to start samhain daemon twice.
3. Need to toggle SELinux into the Permissive mode in order to remove
the samhain_log files from /var/log/.
Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>