Hi Serge,

On Thu, May 4, 2017 at 4:58 PM, Serge E. Hallyn [off-list ref] wrote:

On Thu, May 04, 2017 at 03:07:49PM +0200, Djalal Harouni wrote:

quoted

On Sat, Apr 22, 2017 at 2:17 PM, Djalal Harouni [off-list ref] wrote:

quoted

On Sat, Apr 22, 2017 at 1:28 AM, Andy Lutomirski [off-list ref] wrote:

[...]

quoted

quoted

My point is that all of these need some way to handle configuration
and inheritance, and I don't think that a bunch of per-task prctls is
the right way.  As just an example, saying that interactive users can
autoload modules but other users can't, or that certain systemd
services can, etc, might be nice.  Linus already complained that he
(i.e. user "torvalds" or whatever) should be able to profile the
kernel but that other uids should not be able to.

Neat, maybe this could already be achieved with this interface and
systemd-logind,  "ModulesAutoloadUsers=andy" in logind.conf where
"andy" is the only logged-in user able to trigger and autoload kernel
modules. However maybe we should not restrict too much other bits or
functionality of the other users, please let me will follow up later
on it.

quoted

I personally like my implicit_rights idea, and it might be interesting
to prototype it.

Andy following on the idea of per user settings, I'm curious did you
manage to make some advance on how to store the user settings ? the
user database format is old and not extensible, there was cgmanager or

(v2 is under very very early consideration, would love to stay in the loop
as this is considered)

For user database I'm not aware of any code, but it seems that if the
database or settings are adapted to today use cases then
systemd-logind may use them. Yes if there is something I'll Cc'you.

Thanks!

-- 
tixxdz
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html