* [refpolicy] [PATCH 1/2] system/modutils: Add kernel_search_key(kmod_t) @ 2016-11-27 16:41 Luis Ressel 2016-11-27 16:41 ` [refpolicy] [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap Luis Ressel ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Luis Ressel @ 2016-11-27 16:41 UTC (permalink / raw) To: refpolicy This permission is currently granted in an ifdef(systemd) block, but it's also required on non-systemd systems if signed kernel modules are being used. --- policy/modules/system/modutils.te | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/policy/modules/system/modutils.te b/policy/modules/system/modutils.te index 3bf9bff..afe11af 100644 --- a/policy/modules/system/modutils.te +++ b/policy/modules/system/modutils.te @@ -111,9 +111,9 @@ userdom_dontaudit_search_user_home_dirs(kmod_t) kernel_domtrans_to(kmod_t, kmod_exec_t) -ifdef(`init_systemd',` - kernel_search_key(kmod_t) +kernel_search_key(kmod_t) +ifdef(`init_systemd',` init_rw_stream_sockets(kmod_t) systemd_write_kmod_files(kmod_t) -- 2.10.2 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* [refpolicy] [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap 2016-11-27 16:41 [refpolicy] [PATCH 1/2] system/modutils: Add kernel_search_key(kmod_t) Luis Ressel @ 2016-11-27 16:41 ` Luis Ressel 2016-11-27 20:33 ` Guido Trentalancia 2016-12-04 23:56 ` [refpolicy] [PATCH 1/2] system/modutils: Add kernel_search_key(kmod_t) Luis Ressel 2016-12-07 0:59 ` Chris PeBenito 2 siblings, 1 reply; 22+ messages in thread From: Luis Ressel @ 2016-11-27 16:41 UTC (permalink / raw) To: refpolicy Since Linux 4.8, kmod seems to require this capability for loading certain modules. For example, trying to load my graphics driver i915 without this permission fails with the dmesg error message [drm:ffffffff81497d70] *ERROR* Cannot mount pseudo fs: -1 [drm:ffffffff81497d92] *ERROR* Cannot allocate anonymous inode: -1 i915 0000:00:02.0: [drm:i915_driver_load] allocation failed i915: probe of 0000:00:02.0 failed with error -1 --- policy/modules/system/modutils.te | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/policy/modules/system/modutils.te b/policy/modules/system/modutils.te index afe11af..104a72d 100644 --- a/policy/modules/system/modutils.te +++ b/policy/modules/system/modutils.te @@ -27,7 +27,7 @@ files_pid_file(kmod_var_run_t) # insmod local policy # -allow kmod_t self:capability { dac_override net_raw sys_nice sys_tty_config }; +allow kmod_t self:capability { dac_override net_raw sys_admin sys_nice sys_tty_config }; allow kmod_t self:process { execmem sigchld sigkill sigstop signull signal }; allow kmod_t self:udp_socket create_socket_perms; -- 2.10.2 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* [refpolicy] [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap 2016-11-27 16:41 ` [refpolicy] [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap Luis Ressel @ 2016-11-27 20:33 ` Guido Trentalancia 2016-11-27 21:22 ` Luis Ressel 0 siblings, 1 reply; 22+ messages in thread From: Guido Trentalancia @ 2016-11-27 20:33 UTC (permalink / raw) To: refpolicy Hello. I have the same graphic card and I am not experiencing this problem with kernel 4.8.8... Strange, are you using vanilla kernels ? On Sun, 27/11/2016 at 17.41 +0100, Luis Ressel via refpolicy wrote: > Since Linux 4.8, kmod seems to require this capability for loading > certain modules. For example, trying to load my graphics driver i915 > without this permission fails with the dmesg error message > > [drm:ffffffff81497d70] *ERROR* Cannot mount pseudo fs: -1 > [drm:ffffffff81497d92] *ERROR* Cannot allocate anonymous inode: -1 > i915 0000:00:02.0: [drm:i915_driver_load] allocation failed > i915: probe of 0000:00:02.0 failed with error -1 > --- > ?policy/modules/system/modutils.te | 2 +- > ?1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/policy/modules/system/modutils.te > b/policy/modules/system/modutils.te > index afe11af..104a72d 100644 > --- a/policy/modules/system/modutils.te > +++ b/policy/modules/system/modutils.te > @@ -27,7 +27,7 @@ files_pid_file(kmod_var_run_t) > ?# insmod local policy > ?# > ? > -allow kmod_t self:capability { dac_override net_raw sys_nice > sys_tty_config }; > +allow kmod_t self:capability { dac_override net_raw sys_admin > sys_nice sys_tty_config }; > ?allow kmod_t self:process { execmem sigchld sigkill sigstop signull > signal }; > ? > ?allow kmod_t self:udp_socket create_socket_perms; Regards, Guido ^ permalink raw reply [flat|nested] 22+ messages in thread
* [refpolicy] [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap 2016-11-27 20:33 ` Guido Trentalancia @ 2016-11-27 21:22 ` Luis Ressel 2016-11-27 21:55 ` Luis Ressel ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Luis Ressel @ 2016-11-27 21:22 UTC (permalink / raw) To: refpolicy On Sun, 27 Nov 2016 21:33:05 +0100 Guido Trentalancia via refpolicy <refpolicy@oss.tresys.com> wrote: > Hello. > > I have the same graphic card and I am not experiencing this problem > with kernel 4.8.8... > > Strange, are you using vanilla kernels ? > Not exactly. I'm using Gentoo's hardened-sources kernel, which incorporates the GRSecurity/PaX patchset and some minor distro-specific patches. The exact kernel version I'm using is 4.8.10; on the userland side, I'm using kmod 22. The problem arises on both of my development systems; they're using the i915 and the radeon driver, respectively. So it's indeed interesting that this problem doesn't manifest itself on your system. Possible explanations in order of descending probability: (1) Are you using another kmod version? (2) GRSecurity (I think grsec sometimes requires specific capabilities in situations where vanilla doesn't.) (3) A difference between 4.8.8 and 4.8.10. -- Regards, Luis Ressel ^ permalink raw reply [flat|nested] 22+ messages in thread
* [refpolicy] [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap 2016-11-27 21:22 ` Luis Ressel @ 2016-11-27 21:55 ` Luis Ressel 2016-11-27 22:30 ` Luis Ressel 2016-11-27 22:31 ` Guido Trentalancia 2 siblings, 0 replies; 22+ messages in thread From: Luis Ressel @ 2016-11-27 21:55 UTC (permalink / raw) To: refpolicy By the way, I just had a quick look at the relevant kernel code. Those error messages are printed by drivers/gpu/drm/drm_drv.c:drm_dev_init(). I assume one of the security_sb_... calls in fs/super.c:mount_fs() checks for CAP_SYS_ADMIN and subsequently returns -EPERM. I haven't noticed any relevant differences between my kernel and vanilla 4.8. They might be hidden in one of the aforementioned security_sb_... functions, though. -- Regards, Luis Ressel ^ permalink raw reply [flat|nested] 22+ messages in thread
* [refpolicy] [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap 2016-11-27 21:22 ` Luis Ressel 2016-11-27 21:55 ` Luis Ressel @ 2016-11-27 22:30 ` Luis Ressel 2016-11-27 22:31 ` Guido Trentalancia 2 siblings, 0 replies; 22+ messages in thread From: Luis Ressel @ 2016-11-27 22:30 UTC (permalink / raw) To: refpolicy On Sun, 27 Nov 2016 22:22:18 +0100 Luis Ressel via refpolicy <refpolicy@oss.tresys.com> wrote: > Possible explanations in order of descending probability: > (1) Are you using another kmod version? > (2) GRSecurity (I think grsec sometimes requires specific capabilities > in situations where vanilla doesn't.) > (3) A difference between 4.8.8 and 4.8.10. I've checked the (short) list of places where grsec adds capable(CAP_SYS_ADMIN) requirements. None of them seem to be related to the pseudo filesystem used by the drm code. -- Luis Ressel ^ permalink raw reply [flat|nested] 22+ messages in thread
* [refpolicy] [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap 2016-11-27 21:22 ` Luis Ressel 2016-11-27 21:55 ` Luis Ressel 2016-11-27 22:30 ` Luis Ressel @ 2016-11-27 22:31 ` Guido Trentalancia 2016-11-27 22:50 ` Luis Ressel 2 siblings, 1 reply; 22+ messages in thread From: Guido Trentalancia @ 2016-11-27 22:31 UTC (permalink / raw) To: refpolicy Hello. On Sun, 27/11/2016 at 22.22 +0100, Luis Ressel wrote: > On Sun, 27 Nov 2016 21:33:05 +0100 > Guido Trentalancia via refpolicy <refpolicy@oss.tresys.com> wrote: > > > > > Hello. > > > > I have the same graphic card and I am not experiencing this problem > > with kernel 4.8.8... > > > > Strange, are you using vanilla kernels ? > > > > Not exactly. I'm using Gentoo's hardened-sources kernel, which > incorporates the GRSecurity/PaX patchset and some minor distro- > specific > patches. The exact kernel version I'm using is 4.8.10; on the > userland > side, I'm using kmod 22. > > The problem arises on both of my development systems; they're using > the > i915 and the radeon driver, respectively. So it's indeed interesting > that this problem doesn't manifest itself on your system. Possible > explanations in order of descending probability: > (1) Are you using another kmod version? No, I am using the same 22 version. > (2) GRSecurity (I think grsec sometimes requires specific > capabilities > ????in situations where vanilla doesn't.) If it is specific to Gentoo, you should enclose the new permissions within an ifdef block. Also, do you have an official bug report in Gentoo ? > (3) A difference between 4.8.8 and 4.8.10. There is no evidence of such a change in ChangeLog-4.8.9 and ChangeLog- 4.8.10. >From the error message that you quoted, it sounds like a call to fs/libfs.c:simple_pin_fs() fails in drivers/gpu/drm/drm_drv.c. However, without further evidence, I would not recommend granting the sys_admin permission. Regards, Guido ^ permalink raw reply [flat|nested] 22+ messages in thread
* [refpolicy] [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap 2016-11-27 22:31 ` Guido Trentalancia @ 2016-11-27 22:50 ` Luis Ressel 2016-11-28 17:02 ` Guido Trentalancia 0 siblings, 1 reply; 22+ messages in thread From: Luis Ressel @ 2016-11-27 22:50 UTC (permalink / raw) To: refpolicy On Sun, 27 Nov 2016 23:31:21 +0100 Guido Trentalancia via refpolicy <refpolicy@oss.tresys.com> wrote: > If it is specific to Gentoo, you should enclose the new permissions > within an ifdef block. If this is really grsec's fault, it's a bit of a gray area. Not all refpolicy users use grsec, but it isn't Gentoo-specific, either. We've added grsec-specific permissions to the refpolicy before, though (for example "getty_t self:capability cap_sys_admin" earlier this year). But as I mentioned in my previous mail, I've inspected the grsec patch, and it doesn't appear to add CAP_SYS_ADMIN checks in any relevant code paths, so I'm not convinced this error is really caused by grsec. > Also, do you have an official bug report in Gentoo ? No(t yet). I've been hoping to get this resolved quickly, so I've just send the patch to both refpolicy and Gentoo's SELinux project. > From the error message that you quoted, it sounds like a call to > fs/libfs.c:simple_pin_fs() fails in drivers/gpu/drm/drm_drv.c. Yes, exactly. I've followed the call chain a few levels down, but haven't been able to determine the source of the EPERM at first glance. -- aranea ^ permalink raw reply [flat|nested] 22+ messages in thread
* [refpolicy] [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap 2016-11-27 22:50 ` Luis Ressel @ 2016-11-28 17:02 ` Guido Trentalancia 2016-11-28 21:48 ` Luis Ressel 2016-11-28 22:03 ` [refpolicy] [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap Luis Ressel 0 siblings, 2 replies; 22+ messages in thread From: Guido Trentalancia @ 2016-11-28 17:02 UTC (permalink / raw) To: refpolicy On Sun, 27/11/2016 at 23.50 +0100, Luis Ressel wrote: > On Sun, 27 Nov 2016 23:31:21 +0100 > Guido Trentalancia via refpolicy <refpolicy@oss.tresys.com> wrote: [...] > We've > added grsec-specific permissions to the refpolicy before, though (for > example "getty_t self:capability cap_sys_admin" earlier this year). Thanks for pointing that out ! I have now removed the sys_admin capability locally from the getty module. It is not needed. And, there must be something wrong if the patch you mention forces permissions that are normally unneeded... It seems like it is forcing the users to weaken the policy, which is not what we want. Guido ^ permalink raw reply [flat|nested] 22+ messages in thread
* [refpolicy] [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap 2016-11-28 17:02 ` Guido Trentalancia @ 2016-11-28 21:48 ` Luis Ressel 2016-11-28 21:57 ` Guido Trentalancia 2016-11-28 22:03 ` [refpolicy] [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap Luis Ressel 1 sibling, 1 reply; 22+ messages in thread From: Luis Ressel @ 2016-11-28 21:48 UTC (permalink / raw) To: refpolicy On Mon, 28 Nov 2016 18:02:56 +0100 Guido Trentalancia via refpolicy <refpolicy@oss.tresys.com> wrote: > On Sun, 27/11/2016 at 23.50 +0100, Luis Ressel wrote: > > On Sun, 27 Nov 2016 23:31:21 +0100 > > Guido Trentalancia via refpolicy <refpolicy@oss.tresys.com> wrote: > > [...] > > > We've > > added grsec-specific permissions to the refpolicy before, though > > (for example "getty_t self:capability cap_sys_admin" earlier this > > year). > > Thanks for pointing that out ! I have now removed the sys_admin > capability locally from the getty module. > > It is not needed. And, there must be something wrong if the patch you > mention forces permissions that are normally unneeded... It seems like > it is forcing the users to weaken the policy, which is not what we > want. Well, actually the intent behind this is to *improve* security. The grsec folks check the kernel for APIs which allow potentially dangerous actions without requiring any elevated permissions, and try to secure those APIs -- for example by adding a capable() check. One such case is the TIOCSTI ioctl() on tty devices, which has been used as an avenue for attacks on 'su' sessions (according to the grsec documentation). Of course, there are always a few programs which legitimately use those APIs and thus require additional capabilites on grsec kernels. That's usually not a problem because most of those programs run as root and hence have those capabilities -- unless SELinux gets into the way. In the TIOCSTI case I mentioned above, agetty is one of the few programs out there to use this ioctl (due to a bad design decision that'd be patchable in the source code with moderate effort, I might add). Regards, Luis ^ permalink raw reply [flat|nested] 22+ messages in thread
* [refpolicy] [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap 2016-11-28 21:48 ` Luis Ressel @ 2016-11-28 21:57 ` Guido Trentalancia 2016-11-28 22:14 ` Luis Ressel 0 siblings, 1 reply; 22+ messages in thread From: Guido Trentalancia @ 2016-11-28 21:57 UTC (permalink / raw) To: refpolicy On Mon, 28/11/2016 at 22.48 +0100, Luis Ressel wrote: > On Mon, 28 Nov 2016 18:02:56 +0100 > Guido Trentalancia via refpolicy <refpolicy@oss.tresys.com> wrote: > > > > > On Sun, 27/11/2016 at 23.50 +0100, Luis Ressel wrote: > > > > > > On Sun, 27 Nov 2016 23:31:21 +0100 > > > Guido Trentalancia via refpolicy <refpolicy@oss.tresys.com> > > > wrote:?? > > > > [...] > > > > > > > > We've > > > added grsec-specific permissions to the refpolicy before, though > > > (for example "getty_t self:capability cap_sys_admin" earlier this > > > year).?? > > > > Thanks for pointing that out ! I have now removed the sys_admin > > capability locally from the getty module. > > > > It is not needed. And, there must be something wrong if the patch > > you > > mention forces permissions that are normally unneeded... It seems > > like > > it is forcing the users to weaken the policy, which is not what we > > want. > > Well, actually the intent behind this is to *improve* security. The > grsec folks check the kernel for APIs which allow potentially > dangerous > actions without requiring any elevated permissions, and try to secure > those APIs -- for example by adding a capable() check. That's really?counterproductive when combined with SELinux ! At the moment, if a malicious version of getty gets into the system, it is granted sys_admin capability permissions (which includes privileged and administrative operations). On the other hand, a normal, tight policy (which does not grant the unneeded sys_admin permission) would prevent a malicious getty from carrying out privileged and administrative operations which can damage the system and/or disrupt its normal operation. Guido ^ permalink raw reply [flat|nested] 22+ messages in thread
* [refpolicy] [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap 2016-11-28 21:57 ` Guido Trentalancia @ 2016-11-28 22:14 ` Luis Ressel 2016-11-28 22:24 ` Guido Trentalancia 0 siblings, 1 reply; 22+ messages in thread From: Luis Ressel @ 2016-11-28 22:14 UTC (permalink / raw) To: refpolicy On Mon, 28 Nov 2016 22:57:40 +0100 Guido Trentalancia via refpolicy <refpolicy@oss.tresys.com> wrote: > That's really?counterproductive when combined with SELinux ! > > At the moment, if a malicious version of getty gets into the system, > it is granted sys_admin capability permissions (which includes > privileged and administrative operations). > > On the other hand, a normal, tight policy (which does not grant the > unneeded sys_admin permission) would prevent a malicious getty from > carrying out privileged and administrative operations which can damage > the system and/or disrupt its normal operation. Well, a malicious binary tagged getty_t and running with root privileges could easily wreak enough havoc that the availability or non-availability of CAP_SYS_ADMIN access is somewhat irrelevant. Anyway, I've just revisited the discussion about agetty's cap_sys_admin permission we've had in March. Looks like it may be required on some non-grsec systems, too. (Grep the ML history for the subject "Allow getty the sys_admin capability"). Regards, Luis ^ permalink raw reply [flat|nested] 22+ messages in thread
* [refpolicy] [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap 2016-11-28 22:14 ` Luis Ressel @ 2016-11-28 22:24 ` Guido Trentalancia 2016-11-28 23:03 ` Luis Ressel 0 siblings, 1 reply; 22+ messages in thread From: Guido Trentalancia @ 2016-11-28 22:24 UTC (permalink / raw) To: refpolicy On Sun, 28/11/2016 at 23.14 +0100, Luis Ressel wrote: > On Mon, 28 Nov 2016 22:57:40 +0100 > Guido Trentalancia via refpolicy <refpolicy@oss.tresys.com> wrote: > > > > > That's really?counterproductive when combined with SELinux ! > > > > At the moment, if a malicious version of getty gets into the > > system, > > it is granted sys_admin capability permissions (which includes > > privileged and administrative operations). > > > > On the other hand, a normal, tight policy (which does not grant the > > unneeded sys_admin permission) would prevent a malicious getty from > > carrying out privileged and administrative operations which can > > damage > > the system and/or disrupt its normal operation. > > Well, a malicious binary tagged getty_t and running with root > privileges could easily wreak enough havoc that the availability or > non-availability of CAP_SYS_ADMIN access is somewhat irrelevant. > > Anyway, I've just revisited the discussion about agetty's > cap_sys_admin > permission we've had in March. Looks like it may be required on some > non-grsec systems, too. (Grep the ML history for the subject "Allow > getty the sys_admin capability"). It's very easy !... You can create a patch that reverts commit?7216d000d94342dc347a976a7a6a65f40a2f41cb and then adds an "ifdef grsecurity" for such sys_admin permission (for getty and/or kmod). That way, it won't unnecessarily weaken other systems. Regards, Guido ^ permalink raw reply [flat|nested] 22+ messages in thread
* [refpolicy] [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap 2016-11-28 22:24 ` Guido Trentalancia @ 2016-11-28 23:03 ` Luis Ressel 2016-11-28 23:16 ` Guido Trentalancia 0 siblings, 1 reply; 22+ messages in thread From: Luis Ressel @ 2016-11-28 23:03 UTC (permalink / raw) To: refpolicy On Mon, 28 Nov 2016 23:24:10 +0100 Guido Trentalancia via refpolicy <refpolicy@oss.tresys.com> wrote: > It's very easy !... > > You can create a patch that reverts > commit?7216d000d94342dc347a976a7a6a65f40a2f41cb and then adds an > "ifdef grsecurity" for such sys_admin permission (for getty and/or > kmod). Thanks, I'm perfectly aware of *how* to do this, but I'd like to achieve a broader consensus first (specifically, I'd really like to hear Dominick's and Chris' opinions). Plus, we should first find out if there actually are any other permissions in the refpolicy which pertain to grsec requirements. As I've mentioned, cap_sys_admin may actually be required for agetty even on non-grsec systems (I think Dominick said so, and it used to be granted by distro_redhat, too). And we haven't established yet whether kmod needing cap_sys_admin is grsec-related anyway. Therefore, we might perhaps be left with no grsec-specific permissions at all. :) > Enclosing them in double ifdef should not be necessary. In my opinion, > the former proposal is enough (ifdef grsecurity). Of course double ifdef's wouldn't make much sense. I was merely suggesting that we could use distro_gentoo for this instead of adding a new ifdef variable. Regards, Luis ^ permalink raw reply [flat|nested] 22+ messages in thread
* [refpolicy] [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap 2016-11-28 23:03 ` Luis Ressel @ 2016-11-28 23:16 ` Guido Trentalancia 2016-11-29 1:55 ` Chris PeBenito 0 siblings, 1 reply; 22+ messages in thread From: Guido Trentalancia @ 2016-11-28 23:16 UTC (permalink / raw) To: refpolicy Hello. If you revert the getty commit that I mentioned earlier on, you get back ifdef distro_redhat, so eventually you only need to add the new ifdef grsecurity. Finally, as already explained, on a plain system kmod does not need sys_admin either. It's something related only to your specific system that requires the sys_admin capability permission. Only you can find out whether this is due to grsecurity or other patches... I hope it helps... Regards, Guido On the 29th novembre 2016 00:03:59 CET, Luis Ressel <aranea@aixah.de> wrote: >On Mon, 28 Nov 2016 23:24:10 +0100 >Guido Trentalancia via refpolicy <refpolicy@oss.tresys.com> wrote: > >> It's very easy !... >> >> You can create a patch that reverts >> commit?7216d000d94342dc347a976a7a6a65f40a2f41cb and then adds an >> "ifdef grsecurity" for such sys_admin permission (for getty and/or >> kmod). > >Thanks, I'm perfectly aware of *how* to do this, but I'd like to >achieve >a broader consensus first (specifically, I'd really like to hear >Dominick's and Chris' opinions). > >Plus, we should first find out if there actually are any other >permissions in the refpolicy which pertain to grsec requirements. As >I've mentioned, cap_sys_admin may actually be required for agetty even >on non-grsec systems (I think Dominick said so, and it used to be >granted by distro_redhat, too). And we haven't established yet whether >kmod needing cap_sys_admin is grsec-related anyway. Therefore, we might >perhaps be left with no grsec-specific permissions at all. :) > >> Enclosing them in double ifdef should not be necessary. In my >opinion, >> the former proposal is enough (ifdef grsecurity). > >Of course double ifdef's wouldn't make much sense. I was merely >suggesting that we could use distro_gentoo for this instead of adding a >new ifdef variable. > >Regards, >Luis ^ permalink raw reply [flat|nested] 22+ messages in thread
* [refpolicy] [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap 2016-11-28 23:16 ` Guido Trentalancia @ 2016-11-29 1:55 ` Chris PeBenito 2016-11-29 6:22 ` Nicolas Iooss 0 siblings, 1 reply; 22+ messages in thread From: Chris PeBenito @ 2016-11-29 1:55 UTC (permalink / raw) To: refpolicy On 11/28/16 18:16, Guido Trentalancia via refpolicy wrote: > Hello. > > If you revert the getty commit that I mentioned earlier on, you get back ifdef distro_redhat, so eventually you only need to add the new ifdef grsecurity. > > Finally, as already explained, on a plain system kmod does not need sys_admin either. > > It's something related only to your specific system that requires the sys_admin capability permission. > > Only you can find out whether this is due to grsecurity or other patches... If it turns out to be grsecurity, I'm not eager to add an additional build option to handle this situation. It seems better fitting for Gentoo to carry that patch as they support SELinux with grsecurity. > On the 29th novembre 2016 00:03:59 CET, Luis Ressel <aranea@aixah.de> wrote: >> On Mon, 28 Nov 2016 23:24:10 +0100 >> Guido Trentalancia via refpolicy <refpolicy@oss.tresys.com> wrote: >> >>> It's very easy !... >>> >>> You can create a patch that reverts >>> commit 7216d000d94342dc347a976a7a6a65f40a2f41cb and then adds an >>> "ifdef grsecurity" for such sys_admin permission (for getty and/or >>> kmod). >> >> Thanks, I'm perfectly aware of *how* to do this, but I'd like to >> achieve >> a broader consensus first (specifically, I'd really like to hear >> Dominick's and Chris' opinions). >> >> Plus, we should first find out if there actually are any other >> permissions in the refpolicy which pertain to grsec requirements. As >> I've mentioned, cap_sys_admin may actually be required for agetty even >> on non-grsec systems (I think Dominick said so, and it used to be >> granted by distro_redhat, too). And we haven't established yet whether >> kmod needing cap_sys_admin is grsec-related anyway. Therefore, we might >> perhaps be left with no grsec-specific permissions at all. :) >> >>> Enclosing them in double ifdef should not be necessary. In my >> opinion, >>> the former proposal is enough (ifdef grsecurity). >> >> Of course double ifdef's wouldn't make much sense. I was merely >> suggesting that we could use distro_gentoo for this instead of adding a >> new ifdef variable. >> >> Regards, >> Luis > > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy > -- Chris PeBenito ^ permalink raw reply [flat|nested] 22+ messages in thread
* [refpolicy] [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap 2016-11-29 1:55 ` Chris PeBenito @ 2016-11-29 6:22 ` Nicolas Iooss 2016-11-29 12:53 ` [refpolicy] [PATCH] Allow getty the sys_admin capability (was Re: [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap) Guido Trentalancia 0 siblings, 1 reply; 22+ messages in thread From: Nicolas Iooss @ 2016-11-29 6:22 UTC (permalink / raw) To: refpolicy On Tue, Nov 29, 2016 at 2:55 AM, Chris PeBenito via refpolicy < refpolicy@oss.tresys.com> wrote: > On 11/28/16 18:16, Guido Trentalancia via refpolicy wrote: > > Hello. > > > > If you revert the getty commit that I mentioned earlier on, you get back > ifdef distro_redhat, so eventually you only need to add the new ifdef > grsecurity. > > > > Finally, as already explained, on a plain system kmod does not need > sys_admin either. > > > > It's something related only to your specific system that requires the > sys_admin capability permission. > > > > Only you can find out whether this is due to grsecurity or other > patches... > > If it turns out to be grsecurity, I'm not eager to add an additional > build option to handle this situation. It seems better fitting for > Gentoo to carry that patch as they support SELinux with grsecurity. By the way, I also maintain (and am using) a grsec+SELinux kernel for Arch Linux, but as Arch Linux is currently unsupported by refpolicy I guess this does not change anything. Anyway, for the agetty use of TIOCSTI, when I analyzed the code back in March [1] I found that forbidding it would only cause agetty to miss one keypress if it went into a pause (with "[press ENTER to login]" message). So I do not have a strong opinion on whether cap_sys_admin would be granted or not to support TIOCSTI on grsec kernels. For the kmod part, I do not have such an issue on my system (grepping kmod_t AVC denials in my audit.log did not show anything relevant) but I guess it depends on the video driver which is used. Regards, Nicolas [1] http://oss.tresys.com/pipermail/refpolicy/2016-March/thread.html , more precisely http://oss.tresys.com/pipermail/refpolicy/2016-March/007880.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20161129/a8d3f178/attachment.html ^ permalink raw reply [flat|nested] 22+ messages in thread
* [refpolicy] [PATCH] Allow getty the sys_admin capability (was Re: [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap) 2016-11-29 6:22 ` Nicolas Iooss @ 2016-11-29 12:53 ` Guido Trentalancia 0 siblings, 0 replies; 22+ messages in thread From: Guido Trentalancia @ 2016-11-29 12:53 UTC (permalink / raw) To: refpolicy Hello Nicolas. On Tue, 29/11/2016 at 07.22 +0100, Nicolas Iooss wrote: > On Tue, Nov 29, 2016 at 2:55 AM, Chris PeBenito via refpolicy <refpol > icy at oss.tresys.com> wrote: > > On 11/28/16 18:16, Guido Trentalancia via refpolicy wrote: > > > Hello. > > > > > > If you revert the getty commit that I mentioned earlier on, you > > get back ifdef distro_redhat, so eventually you only need to add > > the new ifdef grsecurity. > > > > > > Finally, as already explained, on a plain system kmod does not > > need sys_admin either. > > > > > > It's something related only to your specific system that requires > > the sys_admin capability permission. > > > > > > Only you can find out whether this is due to grsecurity or other > > patches... > > > > If it turns out to be grsecurity, I'm not eager to add an > > additional > > build option to handle this situation.? It seems better fitting for > > Gentoo to carry that patch as they support SELinux with grsecurity. > > By the way, I also maintain (and am using) a grsec+SELinux kernel for > Arch Linux, but as Arch Linux is currently unsupported by refpolicy I > guess this does not change anything. > Anyway, for the agetty use of?TIOCSTI, when I analyzed the code back > in March [1] I found that forbidding it would only cause agetty to > miss one keypress if it went into a pause (with "[press ENTER to > login]" message). So I do not have a strong opinion on whether I have tested agetty from util-linux version 2.28 (with the non- standard "-p" option necessary to reproduce the problem) and it does not suffer from the problem that you describe above (missing one keypress), although it requires the sys_admin capability permission (possibly for ioctl()). So, my opinion is that it is much better to remove the sys_admin capability permission from the getty module too, because it is dangerous and it does not provide any practical benefit. Also, other versions of getty such as mingetty (commonly used on virtual terminals) do not require the permission. > cap_sys_admin would be granted or not to support TIOCSTI on grsec > kernels. > For the kmod part, I do not have such an issue on my system (grepping > kmod_t AVC denials in my audit.log did not show anything relevant) > but I guess it depends on the video driver which is used. > > Regards, > Nicolas > > [1]?http://oss.tresys.com/pipermail/refpolicy/2016-March/thread.html > , more precisely http://oss.tresys.com/pipermail/refpolicy/2016- > March/007880.html Regards, Guido ^ permalink raw reply [flat|nested] 22+ messages in thread
* [refpolicy] [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap 2016-11-28 17:02 ` Guido Trentalancia 2016-11-28 21:48 ` Luis Ressel @ 2016-11-28 22:03 ` Luis Ressel 2016-11-28 22:08 ` Guido Trentalancia 1 sibling, 1 reply; 22+ messages in thread From: Luis Ressel @ 2016-11-28 22:03 UTC (permalink / raw) To: refpolicy On Mon, 28 Nov 2016 18:02:56 +0100 Guido Trentalancia via refpolicy <refpolicy@oss.tresys.com> wrote: > > We've > > added grsec-specific permissions to the refpolicy before, though > > (for example "getty_t self:capability cap_sys_admin" earlier this > > year). > > Thanks for pointing that out ! I have now removed the sys_admin > capability locally from the getty module. > > It is not needed. And, there must be something wrong if the patch you > mention forces permissions that are normally unneeded... It seems like > it is forcing the users to weaken the policy, which is not what we > want. I do of course agree that unconditionally adding grsec-specific permissions to the refpolicy isn't optimal either. What are your thoughts about adding a new kernel_grsec ifdef, similar to our current distro_* ifdef's? It would apply to the getty_t permission I mentioned earlier, to the kmod_t capability discussed in this thread (as soon as we've confirmed it is indeed grsec-related), and to any other grsec-specific permissions we've added in the past (@Sven, Jason: Do you remember any such permissions?). The vast majority of refpolicy+grsec users are probably gentoo folks, so we could keep these permissions in ifdef(distro_gentoo) blocks, too; but I think that wouldn't be ideal. After all, there may well be other people using this particular combination; it's not gentoo-specific. Regards, Luis ^ permalink raw reply [flat|nested] 22+ messages in thread
* [refpolicy] [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap 2016-11-28 22:03 ` [refpolicy] [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap Luis Ressel @ 2016-11-28 22:08 ` Guido Trentalancia 0 siblings, 0 replies; 22+ messages in thread From: Guido Trentalancia @ 2016-11-28 22:08 UTC (permalink / raw) To: refpolicy On Sun, 28/11/2016 at 23.03 +0100, Luis Ressel wrote: > On Mon, 28 Nov 2016 18:02:56 +0100 > Guido Trentalancia via refpolicy <refpolicy@oss.tresys.com> wrote: [...] > I do of course agree that unconditionally adding grsec-specific > permissions to the refpolicy isn't optimal either. > > What are your thoughts about adding a new kernel_grsec ifdef, similar > to our current distro_* ifdef's? It would apply to the getty_t > permission I mentioned earlier, to the kmod_t capability discussed in > this thread (as soon as we've confirmed it is indeed grsec-related), > and to any other grsec-specific permissions we've added in the past > (@Sven, Jason: Do you remember any such permissions?). Yes, that's the way forward. > The vast majority of refpolicy+grsec users are probably gentoo folks, > so we could keep these permissions in ifdef(distro_gentoo) blocks, > too; Enclosing them in double ifdef should not be necessary. In my opinion, the former proposal is enough (ifdef grsecurity). > but I think that wouldn't be ideal. After all, there may well be > other > people using this particular combination; it's not gentoo-specific. I really look forward to seeing the optimized patches ! Regards, Guido ^ permalink raw reply [flat|nested] 22+ messages in thread
* [refpolicy] [PATCH 1/2] system/modutils: Add kernel_search_key(kmod_t) 2016-11-27 16:41 [refpolicy] [PATCH 1/2] system/modutils: Add kernel_search_key(kmod_t) Luis Ressel 2016-11-27 16:41 ` [refpolicy] [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap Luis Ressel @ 2016-12-04 23:56 ` Luis Ressel 2016-12-07 0:59 ` Chris PeBenito 2 siblings, 0 replies; 22+ messages in thread From: Luis Ressel @ 2016-12-04 23:56 UTC (permalink / raw) To: refpolicy The patch I'm replying was probably missed due to the long discussion about the second patch in the series. Please note that said discussion only applied to the second patch, the first one fixes a wholly independent issue and can be merged. Regards, Luis ^ permalink raw reply [flat|nested] 22+ messages in thread
* [refpolicy] [PATCH 1/2] system/modutils: Add kernel_search_key(kmod_t) 2016-11-27 16:41 [refpolicy] [PATCH 1/2] system/modutils: Add kernel_search_key(kmod_t) Luis Ressel 2016-11-27 16:41 ` [refpolicy] [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap Luis Ressel 2016-12-04 23:56 ` [refpolicy] [PATCH 1/2] system/modutils: Add kernel_search_key(kmod_t) Luis Ressel @ 2016-12-07 0:59 ` Chris PeBenito 2 siblings, 0 replies; 22+ messages in thread From: Chris PeBenito @ 2016-12-07 0:59 UTC (permalink / raw) To: refpolicy On 11/27/16 11:41, Luis Ressel via refpolicy wrote: > This permission is currently granted in an ifdef(systemd) block, but > it's also required on non-systemd systems if signed kernel modules are > being used. > --- > policy/modules/system/modutils.te | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/policy/modules/system/modutils.te b/policy/modules/system/modutils.te > index 3bf9bff..afe11af 100644 > --- a/policy/modules/system/modutils.te > +++ b/policy/modules/system/modutils.te > @@ -111,9 +111,9 @@ userdom_dontaudit_search_user_home_dirs(kmod_t) > > kernel_domtrans_to(kmod_t, kmod_exec_t) > > -ifdef(`init_systemd',` > - kernel_search_key(kmod_t) > +kernel_search_key(kmod_t) > > +ifdef(`init_systemd',` > init_rw_stream_sockets(kmod_t) > > systemd_write_kmod_files(kmod_t) Merged. -- Chris PeBenito ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2016-12-07 0:59 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-11-27 16:41 [refpolicy] [PATCH 1/2] system/modutils: Add kernel_search_key(kmod_t) Luis Ressel 2016-11-27 16:41 ` [refpolicy] [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap Luis Ressel 2016-11-27 20:33 ` Guido Trentalancia 2016-11-27 21:22 ` Luis Ressel 2016-11-27 21:55 ` Luis Ressel 2016-11-27 22:30 ` Luis Ressel 2016-11-27 22:31 ` Guido Trentalancia 2016-11-27 22:50 ` Luis Ressel 2016-11-28 17:02 ` Guido Trentalancia 2016-11-28 21:48 ` Luis Ressel 2016-11-28 21:57 ` Guido Trentalancia 2016-11-28 22:14 ` Luis Ressel 2016-11-28 22:24 ` Guido Trentalancia 2016-11-28 23:03 ` Luis Ressel 2016-11-28 23:16 ` Guido Trentalancia 2016-11-29 1:55 ` Chris PeBenito 2016-11-29 6:22 ` Nicolas Iooss 2016-11-29 12:53 ` [refpolicy] [PATCH] Allow getty the sys_admin capability (was Re: [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap) Guido Trentalancia 2016-11-28 22:03 ` [refpolicy] [PATCH 2/2] system/modutils: Allow kmod to use the sys_admin cap Luis Ressel 2016-11-28 22:08 ` Guido Trentalancia 2016-12-04 23:56 ` [refpolicy] [PATCH 1/2] system/modutils: Add kernel_search_key(kmod_t) Luis Ressel 2016-12-07 0:59 ` Chris PeBenito
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.