Mailing List Archive

Isn't there any mount option that you can pass so that all members of
a certain group can still access sysfs? Perhaps "gid="?

Wkr,
Sven Vermeulen

On Sun, Feb 9, 2014 at 1:35 PM, Luis Ressel <aranea@aixah.de> wrote:
> Hello,
>
>
> I'm currently experimenting with OpenPGP smartcards. For those, I
> need sys-apps/pcsc-lite, which features a daemon (pcscd). This daemon
> has its own user and doesn't run with root permissions. However, it
> needs to access some files in /sys which are only accessible by root
> due to GRKERNSEC_SYSFS_RESTRICT.
>
> I went with the following solution:
> chown root:pcscd /usr/sbin/pcscd
> chmod 0710 /usr/sbin/pcscd
> filecap /usr/sbin/pcscd dac_read_search
>
> Should I just propose the maintainer to add this to the ebuild
> (conditional on a "hardened" USE flag), or would another course of
> action be preferred?
>
>
> Regards,
> Luis Ressel
>
>
> --
> Luis Ressel <aranea@aixah.de>
> GPG fpr: F08D 2AF6 655E 25DE 52BC E53D 08F5 7F90 3029 B5BD

On Sun, 9 Feb 2014 13:43:29 +0100
Sven Vermeulen <sven.vermeulen@siphos.be> wrote:

> Isn't there any mount option that you can pass so that all members of
> a certain group can still access sysfs? Perhaps "gid="?

I guess that would be a safer approach. But I'd prefer a standardized
approach for this - surely there are more non-root applications which
need extended /sys access. I think not every hardened user should have
to figure this out himself.

The best way I can imagine to solve this would be a new eclass. It
would be called in an ebuild (unconditionally) with an user name, would
then check if a certain USE flag (either "hardened" or something more
specific) was set and then add the user in question to a certain group,
perhaps "sysfs". Before doing this for the first time, it would create
that group and ask the user to add an appropriate mount option.

What do you think about this? Is it just overcomplicated or a good way
to go? Also, do you know of other programs which have problems with
GRKERNSEC_SYSFS_RESTRICT? I'd be willing to write the eclass if you
like the idea.


Regards,
Luis Ressel

--
Luis Ressel <aranea@aixah.de>
GPG fpr: F08D 2AF6 655E 25DE 52BC E53D 08F5 7F90 3029 B5BD

On Sun, Feb 09, 2014 at 02:10:47PM +0100, Luis Ressel wrote:
> > Isn't there any mount option that you can pass so that all members of
> > a certain group can still access sysfs? Perhaps "gid="?
>
> I guess that would be a safer approach. But I'd prefer a standardized
> approach for this - surely there are more non-root applications which
> need extended /sys access. I think not every hardened user should have
> to figure this out himself.

It needs to be staged a bit before we should consider optimizations in our
current setup.

> The best way I can imagine to solve this would be a new eclass. It
> would be called in an ebuild (unconditionally) with an user name, would
> then check if a certain USE flag (either "hardened" or something more
> specific) was set and then add the user in question to a certain group,
> perhaps "sysfs". Before doing this for the first time, it would create
> that group and ask the user to add an appropriate mount option.
>
> What do you think about this? Is it just overcomplicated or a good way
> to go? Also, do you know of other programs which have problems with
> GRKERNSEC_SYSFS_RESTRICT? I'd be willing to write the eclass if you
> like the idea.

There are others (I google'd a bit and found a few), but not that much. If
the solution (group access) works and is sufficient, I don't know if there
is a need for creating an eclass.

After all, it might be as simple as:

#v+
use hardened && egroupadd sysfs <username>
#v-

if egroupadd would exist, that is. I haven't looked in detail at the
user.eclass, but that would be all that is needed.

But again, I think this needs to stage a bit - document it on the wiki, test
it out. See if applications still work if they are member of said group
without that group being the primary group, etc.

Wkr,
Sven Vermeulen

On Sun, 9 Feb 2014 15:47:59 +0100
Sven Vermeulen <sven.vermeulen@siphos.be> wrote:

> After all, it might be as simple as:
>
> #v+
> use hardened && egroupadd sysfs <username>
> #v-
>
> if egroupadd would exist, that is. I haven't looked in detail at the
> user.eclass, but that would be all that is needed.

There's no egroupadd, but it's possible to specify additional groups in
a enewuser call. The eclass-less approach would therefore be:

pkg_setup() {
local hardened_group=""
if use hardened ; then
enewgroup sysfs
hardened_group=",sysfs"
fi

enewgroup pcscd
enewuser pcscd -1 -1 /run/pcscd pcscd${hardened_group}
}

However, the eclass would have the advantages:
* single point to rename group or use flag if neccessary
* ability to notify the user about the whole thing and ask him to add
proper mount options

If the eclass approach is accepted, I'd propose to name the eclass
"hardened-utils" - perhaps we need other small helper functions like
this one in the future.


> But again, I think this needs to stage a bit - document it on the
> wiki, test it out. See if applications still work if they are member
> of said group without that group being the primary group, etc.

I'll do that.


Regards,
Luis Ressel

I've had a first look at this. Sadly, there's no gid mount option for
sysfs. Another complication is that the group isn't granted any rights
anyway.

I'll examine what changes to the kernel would be neccessary. (For sure,
one could also create an init script with chown/chmod, but that seems a
bit messy.)


Regards,
Luis Ressel

On Sat, Feb 15, 2014 at 06:03:28PM +0100, Luis Ressel wrote:
> I've had a first look at this. Sadly, there's no gid mount option for
> sysfs. Another complication is that the group isn't granted any rights
> anyway.
>
> I'll examine what changes to the kernel would be neccessary. (For sure,
> one could also create an init script with chown/chmod, but that seems a
> bit messy.)

The init script approach is what most distributions are doing. We also
relabel cpu/online in the selinux_gentoo init script.

But the approach you mentioned on the other mailinglist (regarding reusing
the statement already in use for /proc stuff) seems like a valid case -
interesting to see what's going to happen ;)

Wkr,
Sven Vermeulen

On Mon, 17 Feb 2014 19:24:51 +0000
Sven Vermeulen <swift@gentoo.org> wrote:

> The init script approach is what most distributions are doing. We also
> relabel cpu/online in the selinux_gentoo init script.
>
> But the approach you mentioned on the other mailinglist (regarding
> reusing the statement already in use for /proc stuff) seems like a
> valid case - interesting to see what's going to happen ;)

Yes, I'm trying to find better technical solutions than the init script
approach, both for cpu_online_t and for the sysfs access. I've just
written a kernel patch to make the sysfs gid configurable, let's see if
grsecurity will incorporate it...


Regards,
Luis Ressel