NAS-141460 / 27.0.0-BETA.1 / Disable block device drivers TrueNAS does not use

[ixhamza]

TrueNAS has no use for these block-device drivers, but any root user can load them to create block devices on demand; a customer did this with brd and broke HA failover. Stop building brd, scsi_debug, the NVMe-oF loop and fcloop targets, drbd, aoe, rbd, ublk, null_blk, and bcache. scsi_debug and the NVMe-oF loopbacks especially need this because they appear as ordinary /dev/sd* and /dev/nvme*n* devices that middleware cannot tell apart from real drives; the rest only reduce attack surface.

Testing

Tested with Scale Build. No regressions found from the removed drivers.

[bugclerk]

Jira URL: https://ixsystems.atlassian.net/browse/NAS-141460

[amotin]

I have feeling scsi_debug is used by ZFS CI, if we ever run it on actual TrueNAS. Theoretically I can guess if it to be useful for some of our CI. About others I don't have strong opinion, except I think that if we are going to list all the ways how root user can screw up TrueNAS HA, then this list will be much longer. I don't think it worth to pollute our config with this.

[yocalebo]

I have feeling scsi_debug is used by ZFS CI, if we ever run it on actual TrueNAS. Theoretically I can guess if it to be useful for some of our CI. About others I don't have strong opinion, except I think that if we are going to list all the ways how root user can screw up TrueNAS HA, then this list will be much longer. I don't think it worth to pollute our config with this.

We had a customer create ram devices on their box and break things.

[amotin]

We had a customer create ram devices on their box and break things.

Yeah. I've guessed so from the ticket. I just don't think we can/should do much about it.

[ixhamza]

@amotin agreed! I can limit this to brd, since that is what actually caused the customer issue.

[yocalebo]

We had a customer create ram devices on their box and break things.

Yeah. I've guessed so from the ticket. I just don't think we can/should do much about it.

We should absolutely disable kernel modules that we don't use or expect anyone in the community to use. This is similar to us disabling LVM as well. Why carry around baggage that only harms us?

[amotin]

We should absolutely disable kernel modules that we don't use or expect anyone in the community to use. This is similar to us disabling LVM as well. Why carry around baggage that only harms us?

Because being too much custom may cost more?

[yocalebo]

We should absolutely disable kernel modules that we don't use or expect anyone in the community to use. This is similar to us disabling LVM as well. Why carry around baggage that only harms us?

Because being too much custom may cost more?

I guess we have a different definitions of cost 😄 A customer escalation that goes through the various channels and ends up in an SEE case because our HA got broken seems more costly than not compiling kernel modules.

[amotin]

I guess we have a different definitions of cost 😄 A customer escalation that goes through the various channels and ends up in an SEE case because our HA got broken seems more costly than not compiling kernel modules.

We can't stop customer's foot shooting unless we completely block the shell or turn kernel config into a total mess. And even then somebody may try to insert a SATA drive or do something else unexpected. About blocking HA, I've just proposed to Ameer that for purposes of blocking HA we might only cound dual-ported drives, if those flags of SCSI/NVMe are somehow exposed in sysfs.

[bugclerk]

This PR has been merged and conversations have been locked.
If you would like to discuss more about this issue please use our forums or raise a Jira ticket.