Messages in this thread | | | Subject | Re: [RFC PATCH v4 05/12] fs: add security blob and hooks for block_device | From | Deven Bowers <> | Date | Mon, 20 Jul 2020 09:42:05 -0700 |
| |
On 7/17/2020 5:14 PM, Casey Schaufler wrote:
[...snip]
>> +EXPORT_SYMBOL(security_bdev_free); >> + >> +int security_bdev_setsecurity(struct block_device *bdev, >> + const char *name, const void *value, >> + size_t size) >> +{ >> + return call_int_hook(bdev_setsecurity, 0, bdev, name, value, size); >> +} > > What is your expectation regarding multiple security modules using the > same @name? What do you expect a security module to do if it does not > support a particular @name? You may have a case where SELinux supports > a @name that AppArmor (or KSRI) doesn't. -ENOSYS may be you friend here. >
I expect that some security modules may want to use the same @name / use the data contained with @name. I cannot speak to the future cases of other LSMs, but I expect if they want the raw @value, they'll copy it into their security blob, or interpret @value to a field defined by their security blob.
Originally, I expected a security module that does not implement a particular @name no-op with return 0, not -ENOSYS, but I recognize that error codes are valuable, and it's a trivial change - I'll switch the security hook to call the hooks while allowing -ENOSYS or 0 in the next iteration.
>> +EXPORT_SYMBOL(security_bdev_setsecurity); >> + >> #ifdef CONFIG_PERF_EVENTS >> int security_perf_event_open(struct perf_event_attr *attr, int type) >> {
| |