5:42 p.m.
My amanda clients are seeing the following:
kernel: audit(1144217150.855:17): avc: denied { name_bind } for
pid=3707 comm="sendbackup" src=697
scontext=system_u:system_r:amanda_t:s0
tcontext=system_u:object_r:reserved_port_t:s0 tclass=tcp_socket
And they don't work.
How to fix, please? TIA.
--
Matthew Saltzman
Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs
8 p.m.
I had the same AVC from amanda when nscd was not running; in that
case, amanda (via the C library) has to make a network connection to
the LDAP server (or NIS server, I suppose) in order to look up user
info.
I solved the problem by making sure nscd was started, but it seems you
can also set a boolean (allow_ypbind, I think) to allow these network
connections.
- J<
7:19 a.m.
On Wed, 2006-04-05 at 18:42 -0400, Matthew Saltzman wrote:
My amanda clients are seeing the following:
kernel: audit(1144217150.855:17): avc: denied { name_bind } for
pid=3707 comm="sendbackup" src=697
scontext=system_u:system_r:amanda_t:s0
tcontext=system_u:object_r:reserved_port_t:s0 tclass=tcp_socket
And they don't work.
How to fix, please? TIA.
port 697 is listed as uuidgen in /etc/services, so specifically mapping
it to an amanda port type and allowing amanda to bind to it seems wrong.
If this is just a result of probing for any available low port for NIS,
then the allow_ypbind boolean is likely relevant; try enabling it.
--
Stephen Smalley
National Security Agency
9:17 a.m.
On Thu, 6 Apr 2006, Stephen Smalley wrote:
On Wed, 2006-04-05 at 18:42 -0400, Matthew Saltzman wrote:
> My amanda clients are seeing the following:
>
> kernel: audit(1144217150.855:17): avc: denied { name_bind } for
> pid=3707 comm="sendbackup" src=697
> scontext=system_u:system_r:amanda_t:s0
> tcontext=system_u:object_r:reserved_port_t:s0 tclass=tcp_socket
>
> And they don't work.
>
> How to fix, please? TIA.
port 697 is listed as uuidgen in /etc/services, so specifically mapping
it to an amanda port type and allowing amanda to bind to it seems wrong.
If this is just a result of probing for any available low port for NIS,
then the allow_ypbind boolean is likely relevant; try enabling it.
That stops the denial messages, but Amanda still isn't working. It fails
with "too many dumper retry". I'm not getting denials, though, so I
suppose that must be something else?
(Running nscd doesn't seem to help matters.)
Also, this seems strange as a solution as this network doesn't run NIS. I
do have all the amanda-related ports open on both server and client. I
had no problems running amanda under FC4. My server is FC4 and it backs
itself and an RH7.3 machine up with no problems. Only my FC5 clients have
issues.
--
Matthew Saltzman
Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs
9:27 a.m.
On Mon, 2006-04-10 at 10:17 -0400, Matthew Saltzman wrote:
On Thu, 6 Apr 2006, Stephen Smalley wrote:
> On Wed, 2006-04-05 at 18:42 -0400, Matthew Saltzman wrote:
>> My amanda clients are seeing the following:
>>
>> kernel: audit(1144217150.855:17): avc: denied { name_bind } for
>> pid=3707 comm="sendbackup" src=697
>> scontext=system_u:system_r:amanda_t:s0
>> tcontext=system_u:object_r:reserved_port_t:s0 tclass=tcp_socket
>>
>> And they don't work.
>>
>> How to fix, please? TIA.
>
> port 697 is listed as uuidgen in /etc/services, so specifically mapping
> it to an amanda port type and allowing amanda to bind to it seems wrong.
> If this is just a result of probing for any available low port for NIS,
> then the allow_ypbind boolean is likely relevant; try enabling it.
That stops the denial messages, but Amanda still isn't working. It fails
with "too many dumper retry". I'm not getting denials, though, so I
suppose that must be something else?
(Running nscd doesn't seem to help matters.)
Try installing the enableaudit.pp policy module, i.e.
semodule -b /usr/share/selinux/targeted/enableaudit.pp
and retrying, then recheck your audit messages for anything relevant
(but note that there may be a lot of irrelevant audit messages enabled
by it).
That is the equivalent in FC5 to the old 'make enableaudit load' on
policy sources in FC4 and FC3.
Then you revert to the normal policy via
semodule -b /usr/share/selinux/targeted/base.pp
Also, this seems strange as a solution as this network doesn't
run NIS. I
do have all the amanda-related ports open on both server and client. I
had no problems running amanda under FC4. My server is FC4 and it backs
itself and an RH7.3 machine up with no problems. Only my FC5 clients have
issues.
I agree that allow_ypbind needs to be renamed/generalized.
--
Stephen Smalley
National Security Agency
1:19 p.m.
On Mon, 10 Apr 2006, Stephen Smalley wrote:
On Mon, 2006-04-10 at 10:17 -0400, Matthew Saltzman wrote:
> On Thu, 6 Apr 2006, Stephen Smalley wrote:
>
>> On Wed, 2006-04-05 at 18:42 -0400, Matthew Saltzman wrote:
>>> My amanda clients are seeing the following:
>>>
>>> kernel: audit(1144217150.855:17): avc: denied { name_bind } for
>>> pid=3707 comm="sendbackup" src=697
>>> scontext=system_u:system_r:amanda_t:s0
>>> tcontext=system_u:object_r:reserved_port_t:s0 tclass=tcp_socket
>>>
>>> And they don't work.
>>>
>>> How to fix, please? TIA.
>>
>> port 697 is listed as uuidgen in /etc/services, so specifically mapping
>> it to an amanda port type and allowing amanda to bind to it seems wrong.
>> If this is just a result of probing for any available low port for NIS,
>> then the allow_ypbind boolean is likely relevant; try enabling it.
>
> That stops the denial messages, but Amanda still isn't working. It fails
> with "too many dumper retry". I'm not getting denials, though, so I
> suppose that must be something else?
>
> (Running nscd doesn't seem to help matters.)
Try installing the enableaudit.pp policy module, i.e.
semodule -b /usr/share/selinux/targeted/enableaudit.pp
and retrying, then recheck your audit messages for anything relevant
(but note that there may be a lot of irrelevant audit messages enabled
by it).
That is the equivalent in FC5 to the old 'make enableaudit load' on
policy sources in FC4 and FC3.
Then you revert to the normal policy via
semodule -b /usr/share/selinux/targeted/base.pp
Well, I feel silly now. The problem was failure to include
ip_conntrack_amanda in /etc/sysconfig/iptables-config. I always seem to
forget that. Is there a reason it shouldn't be automated somehow when
amanda or amanda-client is installed?
The AVC still reports denied (I usually get several, but with different
port numbers), but amanda runs anyway.
"setsebool allow_ypbind 1" stops the denial messages.
BTW, audit2allow for that AVC says "allow amanda_t
reserved_port_t:tcp_socket name_bind". I haven't tried that yet, as I
wasn't sure whether it or the boolean was the right thing to do, and I
wasn't sure exactly what the right command was to accomplish the
suggested change.
> Also, this seems strange as a solution as this network doesn't run NIS. I
> do have all the amanda-related ports open on both server and client. I
> had no problems running amanda under FC4. My server is FC4 and it backs
> itself and an RH7.3 machine up with no problems. Only my FC5 clients have
> issues.
I agree that allow_ypbind needs to be renamed/generalized.
--
Matthew Saltzman
Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs
6578
days inactive
6589
days old
selinux@lists.fedoraproject.org
5 comments
3 participants
participants (3)
-
Jason L Tibbitts III -
Matthew Saltzman -
Stephen Smalley