Problems starting FreeRadius after 3.0.23 install

[Weisteen Per]

Hi

Should of course have checked this before I started scratching my head but the change from CapabilityBoundingSet to AmbientCapabilities has already been implemented in the latest radius.service file for RedHat at GitHub. 

./PerW


> -----Original Message-----
> From: Freeradius-Users <freeradius-users-
> bounces+per.weisteen=telenor.no at lists.freeradius.org> On Behalf Of
> Weisteen Per
> Sent: mandag 27. september 2021 09:25
> To: FreeRadius users mailing list <freeradius-users at lists.freeradius.org>
> Subject: RE: Problems starting FreeRadius after 3.0.23 install
> 
> Hi Alan
> 
> Thanks for your time.
> 
> I checked the systemd man pages and did some Googling and found info
> suggesting that one should use AmbientCapabilities to set capabilities while
> CapabilityBoundingSet limits capabilities.
> That seems to have done the trick. Startup is without errors now. I haven’t
> experimented with all capabilities, but this works ok at least.
> 
> AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
> CAP_NET_BROADCAST CAP_NET_RAW
> 
> BTW: SElinux is disabled in my system.
> 
> Regards,
> ./PerW
> 
> 
> > -----Original Message-----
> > From: Freeradius-Users <freeradius-users-
> > bounces+per.weisteen=telenor.no at lists.freeradius.org> On Behalf Of
> > bounces+Alan
> > DeKok
> > Sent: fredag 24. september 2021 14:23
> > To: FreeRadius users mailing list
> > <freeradius-users at lists.freeradius.org>
> > Subject: Re: Problems starting FreeRadius after 3.0.23 install
> >
> > On Sep 24, 2021, at 6:04 AM, Weisteen Per <per.weisteen at telenor.no>
> > wrote:
> > > Have just installed Freeradius 3.0.23 on my CentOS 7 test-servers as
> > described in https://networkradius.com/packages/ .
> > > I'm not using LDAP so I've skipped that part.
> >
> >   OK.
> >
> > > I'm also not using radiusd:radiusd as userid:groupid due to
> > > administrative
> > naming rules, but got a xxxxrad:xxxxrad as userid:groupid instead.
> > > I've changed ownership for all files under /etc/raddb and
> > > /var/log/radiusd
> > to xxxxrad:xxxxrad, changed user and group in radius.conf accordingly.
> > > Also copied the supplied /usr/lib/systemd/system/radiusd.service
> > > into
> > /etc/systemd/system/radiusd.service and changed User and Group here
> > too.
> >
> >   It's best to have the file permissions as owned by user "root", and
> > group "xxxrad".  You typically don't want a public-facing service to
> > own the files it reads.  If there's a vulnerability, then an attacker
> > can over-write the configuration files.  Which is usually bad.
> >
> 
> Ok, will do.
> 
> > > Running radius -X as root gives no error messages.
> > >
> > > When starting radius through systemctl start radiusd I get "Failed
> > > to start
> > FreeRADIUS multi-protocol policy server."
> > >
> > > Doing su - xxxxrad and the running radius -X gives these messages:
> > > Failed binding to interface net1: Operation not permitted
> > > /etc/raddb/sites-enabled/default[59]: Error binding to port for
> > > 10.141.8.20 port 1812
> >
> >   That's an error from the operating system.
> >
> > > I've removed the comment that was in front of the
> > > CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
> > > CAP_NET_BROADCAST CAP_NET_RAW CAP_SETUID CAP_SETGID
> > CAP_CHOWN CAP_DAC_OVERRIDE In radius.service.
> >
> >   That's good, but it seems not enough.
> >
> >   There's some magic on your OS (SeLinux?) which is preventing the
> > server from binding to the "net1" interface.  You'll have to figure it
> > out.  And if you do, *please* update the Wiki so other people don't run
> into the same issue.
> >
> >   I don't run SeLinux because it's useless for most purposes.  It
> > rarely helps, it's hard to configure, and it gets in the way.
> >
> >   Alan DeKok.
> >
> >
> > -
> > List info/subscribe/unsubscribe? See
> > http://www.freeradius.org/list/users.html
> 
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html