Use SELinux ioctl whitelist

[DemiMarie]

Currently, ioctls are not whitelisted. Whitelisting them would significantly improve security.

[ghost]

On Wed, Aug 28, 2019 at 06:57:17AM -0700, Demi Marie Obenour wrote: Currently, ioctls are not whitelisted. Whitelisting them would significantly improve security.

Sure but theres some difficulties with that. In a general purpose os, whitelisting is probably less practical than blacklisting. But even blacklisting is hard if there is no comprehensive list of ioctls available. Also ioctls are often hardware specific i believe? The approach that i take with my personal policy with regards to ioctls is: I dont leverage it by default, but i make it easy to leverage it by ensuring that all permissions used in the policy originate from a single source/module (permission sets: class_permissions.cil) That way one can just replace the module that has the permission sets with one that excludes the generic ioctl permission (sed /ioctl//). Thereby removing all ioctl permissions policy-wide. Then one can essentially leverage xperms by using auditallow rules and audit2allow to only allow the ioctls one needs in ones particular scenario with ones particular hardware This, IMHO, is the most effective and practical way to leverage xperms.

…

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #76

-- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift

[DemiMarie]

@doverride Most programs have no reason to use any of these hardware-specific ioctls, so they should not be allowed by default. Programs that need to use them should be explicitly allowed to use them. Ioctls are a very large attack surface, so blanketly allowing them is a bad idea in my opinion.

Android whitelists ioctls, and I suspect its list is a good one.

[ghost]

On Wed, Aug 28, 2019 at 08:41:05AM -0700, Demi Marie Obenour wrote: @doverride Most programs have no reason to use any of these hardware-specific ioctls, so they should not be allowed by default. Programs that need to use them should be explicitly allowed to use them. Ioctls are a very large attack surface, so blanketly allowing them is a bad idea in my opinion. Android whitelists ioctls, and I suspect its list is a good one.

I admire your optimism but i think you might be underestimating things a little. We're not talking phones here To give you an impression: there are hundreds of ioctl operations for tens of different "models" just from drm alone

…

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #76 (comment)

-- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift

[fishilico]

Did you perform tests with a Linux system? Contrary to Android, many applications use tty ioctls (TCGETS, TCSETSW, TIOCGWINSZ, etc.) with their stdout file descriptor, many changes attributes to their network sockets, etc.

It is unclear to me how much work needs to be done in order to implement ioctl restrictions that make sense on a Linux system which is not an embedded one (such as Android). If the Android list seems to be good, could you please provide a link to it?

[ghost]

On Wed, Aug 28, 2019 at 11:35:17AM -0700, Nicolas Iooss wrote: Did you perform tests with a Linux system? Contrary to Android, many applications use tty ioctls (`TCGETS`, `TCSETSW`, `TIOCGWINSZ`, etc.) with their `stdout` file descriptor, many changes attributes to their network sockets, etc. It is unclear to me how much work needs to be done in order to implement ioctl restrictions that make sense on a Linux system which is not an embedded one (such as Android). If the Android list seems to be good, could you please provide a link to it?

https://android.googlesource.com/platform/system/sepolicy/+/ac74f62cd5f7d3d28a7386751c2218f310e6711b/public/ioctl_defines Its missing the drm amdgpu ioctls. So that list wouldnt work on my laptop and thats only looking at drm...

…

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #76 (comment)

-- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift

[DemiMarie]

@fishilico @doverride First, many applications do not use very many ioctls, so per-application whitelists should be doable. It does take work, but no more than creating per-application policies.

A good starting point would be to remove ioctl from some of the interfaces. My understanding is that most applications do not use filesystem ioctls, for example. In other cases, the list of ioctls is well-documented (such as TTYs) and we can whitelist a set of safe ones. In particular, TIOCSTI should not be on the whitelist, as it has been a source of numerous security problems and has few valid use cases. Another good use-case is network ioctls: while some generic ioctls should be allowed, most applications have no business calling device-specific ioctls. Since most vulnerabilities are in the latter, this significantly reduces attack surface. An even clearer case is ioctls that change network configuration: there is absolutely no reason for most applications to be calling them.

[ghost]

On Wed, Aug 28, 2019 at 11:45:56AM -0700, Demi Marie Obenour wrote: @fishilico @doverride First, many applications do not use very many ioctls, so per-application whitelists should be doable. It does take work, but no more than creating per-application policies. A good starting point would be to remove `ioctl` from some of the interfaces. My understanding is that most applications do not use filesystem ioctls, for example. In other cases, the list of ioctls is well-documented (such as TTYs) and we can whitelist a set of safe ones. In particular, TIOCSTI should not be on the whitelist, as it has been a source of numerous security problems and has few valid use cases. Another good use-case is network ioctls: while some generic ioctls should be allowed, most applications have no business calling device-specific ioctls. Since most vulnerabilities are in the latter, this significantly reduces attack surface. An even clearer case is ioctls that change network configuration: there is absolutely no reason for most applications to be calling them.

I suppose we could focus on device nodes, and then just use the blacklist approach (not sure if below would work): (permissionx all_chr_ioctl_except (ioctl chr_file (not (0x0000abcd 0x0000efgh 0x0000ijkl))) then just use "all_chr_ioctl_except" instead of "ioctl" in the chr_file permissions sets That would already help, but yes even then you would need to be able to identify what to blacklist

…

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #76 (comment)

-- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift

[DemiMarie]

@doverride I think we can use whitelisting for some device nodes, such as PTYs. Also, I think we can just remove ioctl permissions from most filesystem interfaces. Most applications never use filesystem ioctls.

For network devices, I think we can afford to whitelist ioctls that are device-independent and non-privileged. Only certain applications should use device-dependent ioctls.

[pebenito]

I'm open to patches that address this situation. I wouldn't mind improving things, but I'm highly skeptical, for the same reasons as already stated.