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
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
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
On Sun, 27 Nov 2016 21:33:05 +0100
Guido Trentalancia via refpolicy <[email protected]> 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
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
On Sun, 27 Nov 2016 22:22:18 +0100
Luis Ressel via refpolicy <[email protected]> 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
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 <[email protected]> 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
On Sun, 27 Nov 2016 23:31:21 +0100
Guido Trentalancia via refpolicy <[email protected]> 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
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 <[email protected]> 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
On Mon, 28 Nov 2016 18:02:56 +0100
Guido Trentalancia via refpolicy <[email protected]> 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 <[email protected]> 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
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 <[email protected]> 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 <[email protected]>
> > > 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
On Mon, 28 Nov 2016 18:02:56 +0100
Guido Trentalancia via refpolicy <[email protected]> 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
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 <[email protected]> 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
On Mon, 28 Nov 2016 22:57:40 +0100
Guido Trentalancia via refpolicy <[email protected]> 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
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 <[email protected]> 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
On Mon, 28 Nov 2016 23:24:10 +0100
Guido Trentalancia via refpolicy <[email protected]> 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
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 <[email protected]> wrote:
>On Mon, 28 Nov 2016 23:24:10 +0100
>Guido Trentalancia via refpolicy <[email protected]> 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
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 <[email protected]> wrote:
>> On Mon, 28 Nov 2016 23:24:10 +0100
>> Guido Trentalancia via refpolicy <[email protected]> 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
On Tue, Nov 29, 2016 at 2:55 AM, Chris PeBenito via refpolicy <
[email protected]> 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
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
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
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