[LU-5560] SELinux support on the client side

• Status: Resolved
• Project: Lustre
• Fix Version/s: Lustre 2.8.0, Lustre 2.9.0
• Type: Improvement
• Priority: Minor
• Reporter: Sebastien Buisson (Inactive)
• Assignee: Oleg Drokin
• Resolution: Fixed
• Labels: patch

Description

The aim is to be able to enforce SELinux security policies on Lustre from SELinux-enabled clients.

It requires to properly initiate file security context on client side, and store it on server side via extended attribute.

Issue Links

• is blocked by: LU-6784 Defects in SELinux support
• is related to: LUDOC-335 Documentation for SELinux Feature
• is related to: LU-8654 obd_connect_data handling must accoun...
• is related to: LU-9193 Multiple hangs observed with many op...
• is related to: LU-6950 Lustre mount throws away SELinux cont...
• is related to: LU-7417 Permission Denied on enforcing SElinu...

Comments

[Sebastien Buisson (Inactive)]

As a first implementation, I added a call to a new function ll_init_security() after the calls to d_instantiate() in ll_create_it() and ll_new_node(). This new function retrieves security context via security_inode_init_security(), and stores it in extended attribute in MDT with ll_setxattr().

To ensure security context coherency between clients, this basic implementation does not cache inodes at all. This is why I created a new function ll_drop_inode(), and also modified ll_ddelete() to always return 1 when SELinux is enabled.

Of course this first, basic implementation severely hurts metadata performance because of the inode cache drop.

I uploaded the patch here:
http://review.whamcloud.com/11648

[Sebastien Buisson (Inactive)]

Ideally, to ensure security context coherency between clients, a new lock (let's call it MDS_INODELOCK_SECURITY) should be used to synchronize updates:

• take MDS_INODELOCK_SECURITY lock at setxattr time if SELinux is enabled and xattr is security.selinux (this also requires modifying mdc_enqueue() to ask for MDS_INODELOCK_SECURITY if it is called with IT_SETXATTR);
• when asked to release MDS_INODELOCK_SECURITY lock in ll_md_blocking_ast(), delete inode with a call to generic_delete_inode(), so that further access to the inode will retrieve fresh security context.

My problem is the Lustre code is too complicated, I am not able to do what I described here. Could you help with the part taking the new MDS_INODELOCK_SECURITY lock at setxattr time?

[Bruno Faccini (Inactive)]

Hello Seb, this looks like a non-trivial task!
Are there any paper/notes to describe all the situations that will need to be handled ?

[Sebastien Buisson (Inactive)]

Hi Bruno,

What do you think of the suggestion from Andrew Perepechko in http://review.whamcloud.com/11648 to modify MDS behavior so that we cancel lookup lock in case of change on 'security.selinux" xattr?

Can we exchange by IRC on #lustre for instance (sorry, no Skype available for me).

Cheers,
Sebastien.

[Peter Jones]

Oleg is looking into this

[Andreas Dilger]

Sebastien, do we need a separate lock bit for SELinux? We already have client-side xattr cache introduced in 2.5 that should result in the client-side xattr cache being cleaned if the selinux xattr is changed.

[Sebastien Buisson (Inactive)]

The xattr cache is only filled in case of getxattr, not setxattr. So the MDS_INODELOCK_XATTR lock is not hold by a client creating a file with SELinux attributes. Then if another client modifies the SELinux attributes, it will not lead to any action on the client that initially created the file.

Moreover, security context is stored in (struct inode*)->i_security besides its representation as an xattr in the Lustre/ldiskfs case. So in case of SELinux attributes modification by another client, the action required on the client that initially created the file would be to call delete_inode(), in order to force a new lookup of the inode. This could be overkill, maybe there is another mechanism already available in Lustre to force lookup without having to delete the inode.

[Sebastien Buisson (Inactive)]

Hi,

In order to make things easier, and because the coherency need comes from a very special use case, I have decided to tackle it separately.
This is why I have pushed a new patch that stores security information permanently, and filters out security.selinux xattr from xattr cache (because security information is already in system slab cache).
Please see:
http://review.whamcloud.com/11648

Sebastien.

[Wang Shilong (Inactive)]

Hello Sebastien Buisson,

Could you please tell me how do you mount lustre client under enforcing mode with this patch?
btw, do you have some selinux testsuite to verify this patch works?

Best Regards,
Wang Shilong

[Sebastien Buisson (Inactive)]

Hi,

There is no mount option required. As soon as SELinux is enforced on the client node, it will be taken into account at the Lustre level.
I do not have specific testsuite for this patch for now.

Cheers,
Sebastien.

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch http://review.whamcloud.com/11648/
Subject: LU-5560 llite: basic support of SELinux in CLIO
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 8a11cb6282cfbdc8617b809344e6a11223e86a38

[Sebastien Buisson (Inactive)]

Hi,

Please find attached the proposed Test Plan for SELinux support on the client side.

Sebastien.

[Gerrit Updater]

Sebastien Buisson ([e-mail]) uploaded a new patch: http://review.whamcloud.com/15818
Subject: LU-5560 tests: add sanity-selinux.sh
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 38ed4c38796c1903f4cfd553d886f7fbaebba972

[Sebastien Buisson (Inactive)]

Hi,

Here is an updated Test Plan for SELinux support on the client side, including functional tests.

Sebastien.

[Sebastien Buisson (Inactive)]

Hi,

Here is an updated Test Plan for SELinux support on the client side, including remarks from Andrew Perepechko.

Sebastien.

[Sarah Liu]

Hello,

For the upgrade/downgrade testing of this feature, how would you like the test be implemented? Is there any specific requirement?

Thanks,
Sarah

[Joseph Gmitter (Inactive)]

This work has landed for the 2.8.0 release in patch http://review.whamcloud.com/#/c/11648/

[James Nunez (Inactive)]

Reopening ticket because the patch containing the SELinux test suite never landed; http://review.whamcloud.com/#/c/15818.

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch http://review.whamcloud.com/19970/
Subject: LU-5560 obd: reserve connection flag OBD_CONNECT2_FILE_SECCTX
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: a06b32d1c49eb6c31aeba556795841730de37006

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch http://review.whamcloud.com/15818/
Subject: LU-5560 tests: add sanity-selinux.sh
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: bfca8338e5f2ae1b7c16cc1d0c2376523d68685e

[Peter Jones]

Reclosing as the test script landed. Sebastien, you should open a new ticket to track the atomic context transfer during create patch also still in flight - http://review.whamcloud.com/#/c/19971/

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch http://review.whamcloud.com/19971/
Subject: LU-5560 security: send file security context for creates
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 4ea24bdabb2b318721605bd185c32bbc1e9bc924