Well, I guess this swings back around to the SSG content then.

1) If we don't need NetworkManager, then it should be disabled as an unnecessary service.
2) If the SSG wants to dictate NM, then we need to know exactly what polkit rules should, and should not, be in place
3) Since polkit is a bunch of Javascript, this is going to be a good old bunch of fun to audit without a live implementation validation

I know how to write polkit rules, but the SSG needs to dictate polkit rules for those services that rely on polkit. Otherwise, there's a lovely gaping hole in the system security that can effectively be used to run pretty much anything with root permissions.

Thanks,

Trevor

On Mon, Sep 17, 2018 at 4:27 AM Matus Marhefka <mmarhefk@redhat.com> wrote:
Hello Thomas,

thank you for the clarification, we appreciate your help.

@Trevor: Do you have any more questions considering NetworkManager requirements? As Thomas and Lubomir are in the thread it would be best to discuss and clarify with them.

Best Regards,
Matus

On Mon, Sep 10, 2018 at 4:44 PM Thomas Haller <thaller@redhat.com> wrote:
On Mon, 2018-09-10 at 15:02 +0200, Matus Marhefka wrote:

Hi,

> Hello Thomas, Lubomir, can you help us on this topic? There are some
> questions which we (Security Compliance team) are unable to answer
> and we need your help:
>
> 1. Is NetworkManager meant to be a required service in RHEL 7?

No, it is not required.


> 2. What is the proper mechanism for restricting DBus access to
> NetworkManager to only allowed users (i.e. no GUI utilities, etc...)?
> Do you have any pointers (manuals/blogs/...)?

It's not in particular about GUI utilities. All NetworkManager clients
use the D-Bus API of NetworkManager.

Clients are authenticated as the (user of the) process that is talking
to NetworkManager's D-Bus (e.g. the user who invokes nmcli).

Note that requests from user id 0 (root) are always allowed by
NetworkManager. All other Requests are autorized using PolKit [1]. See
the .policy file ([2], [3]) for the actions available to
NetworkManager.

Configuring authorization with PolKit is AFAIK done by writing rules.
But how to do that correctly, please ask PolKit maintainers.


[1] https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html
[1] /usr/share/polkit-1/actions/org.freedesktop.NetworkManager.policy
[2] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/data/org.freedesktop.NetworkManager.policy.in.in?id=c87faf07a10900804b914057a2673e0e070b0af4


I am not aware of issues regarding hidepid [3]. But probably such
configuration is little tested and used. As far as NetworkManager is
concerned, it should work. I don't know what PolKit makes of that,
worst case it will reject the request (as said: requests from root are
not authorized via PolKit).

[3] https://bugzilla.gnome.org/show_bug.cgi?id=764502


best.
Thomas

>
> Thanks,
> Matus Marhefka
>
>
> On Sun, Sep 9, 2018 at 6:57 PM, Trevor Vaughan <
> tvaughan@onyxpoint.com> wrote:
> > Oh, this is also related to the 'hidepid' discussion. If
> > NetworkManager is going to be a blocker on hidepid, then it needs
> > to be fully locked down and I can't find good guidance on doing
> > that.
> >
> > On Sun, Sep 9, 2018 at 12:56 PM Trevor Vaughan <
> > tvaughan@onyxpoint.com> wrote:
> > > Everyone I know hates that on servers.
> > >
> > > Apparently firewalld tries to use it and it's mentioned in the
> > > SSG explicitly.
> > >
> > > Since it's mentioned, there needs to be surrounding guidance on
> > > how to make it not be so "user friendly".
> > >
> > > If it's not needed, it should fall under "run no unnecessary
> > > services" and be slated to be killed explicitly since it does try
> > > to give people the ability to do things in the network stack by
> > > default (which they should not have).
> > >
> > > Thanks,
> > >
> > > Trevor
> > >
> > > On Sat, Sep 8, 2018 at 12:38 PM Matthew <simontek@gmail.com>
> > > wrote:
> > > > Why is NetworkManager required? I hate that on servers.
> > > >
> > > > On Fri, Sep 7, 2018, 5:42 PM Trevor Vaughan <
> > > > tvaughan@onyxpoint.com> wrote:
> > > > > As I was digging around some of the content, I realized that
> > > > > I had a question that I never managed to get answered.
> > > > >
> > > > > Namely, is NetworkManager now a required service?
> > > > >
> > > > > If so, what is the proper mechanism for restricting DBus
> > > > > access to NetworkManager to only allowed users (i.e. no GUI
> > > > > utilities, etc...).
> > > > >
> > > > > I feel like this should be codified somewhere in the SSG
> > > > > content.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Trevor
> > > > >
> > > > > --
> > > > > Trevor Vaughan
> > > > > Vice President, Onyx Point, Inc
> > > > > (410) 541-6699 x788
> > > > >
> > > > > -- This account not approved for unencrypted proprietary
> > > > > information --
> > > > > _______________________________________________
> > > > > scap-security-guide mailing list --
> > > > > scap-security-guide@lists.fedorahosted.org
> > > > > To unsubscribe send an email to
> > > > > scap-security-guide-leave@lists.fedorahosted.org
> > > > > Fedora Code of Conduct:
> > > > > https://getfedora.org/code-of-conduct.html
> > > > > List Guidelines:
> > > > > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > > List Archives:
> > > > > https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedorahosted.org
> > > >
> > > > _______________________________________________
> > > > scap-security-guide mailing list --
> > > > scap-security-guide@lists.fedorahosted.org
> > > > To unsubscribe send an email to
> > > > scap-security-guide-leave@lists.fedorahosted.org
> > > > Fedora Code of Conduct:
> > > > https://getfedora.org/code-of-conduct.html
> > > > List Guidelines:
> > > > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > List Archives:
> > > > https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedorahosted.org
> > >
> > >
> > > --
> > > Trevor Vaughan
> > > Vice President, Onyx Point, Inc
> > > (410) 541-6699 x788
> > >
> > > -- This account not approved for unencrypted proprietary
> > > information --
> >
> >


--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --