If I attempt to use nsupdate from under an ordinary user (which shouldn't be a problem, should it?), then I see
audit(1079022100.499:0): avc: denied { bind } for pid=18759 exe=/usr/bin/nsupdate scontext=user_u:user_r:user_t tcontext=user_u:user_r:user_t tclass=netlink_socket audit(1079022100.499:0): avc: denied { getattr } for pid=18759 exe=/usr/bin/nsupdate scontext=user_u:user_r:user_t tcontext=user_u:user_r:user_t tclass=netlink_socket audit(1079022100.499:0): avc: denied { write } for pid=18759 exe=/usr/bin/nsupdate scontext=user_u:user_r:user_t tcontext=user_u:user_r:user_t tclass=netlink_socket audit(1079022100.500:0): avc: denied { read } for pid=18759 exe=/usr/bin/nsupdate scontext=user_u:user_r:user_t tcontext=user_u:user_r:user_t tclass=netlink_socket
Not sure what this is all about.
Aleksey Nogin wrote: Is nsupdate a program to be run by an ordinary user? If yes we need to define a security context for nsupdate to allow it to access the netlink_sockets.
If we allow users access that any rogue app the user runs could access the network devices.
Dan
If I attempt to use nsupdate from under an ordinary user (which shouldn't be a problem, should it?), then I see
audit(1079022100.499:0): avc: denied { bind } for pid=18759 exe=/usr/bin/nsupdate scontext=user_u:user_r:user_t tcontext=user_u:user_r:user_t tclass=netlink_socket audit(1079022100.499:0): avc: denied { getattr } for pid=18759 exe=/usr/bin/nsupdate scontext=user_u:user_r:user_t tcontext=user_u:user_r:user_t tclass=netlink_socket audit(1079022100.499:0): avc: denied { write } for pid=18759 exe=/usr/bin/nsupdate scontext=user_u:user_r:user_t tcontext=user_u:user_r:user_t tclass=netlink_socket audit(1079022100.500:0): avc: denied { read } for pid=18759 exe=/usr/bin/nsupdate scontext=user_u:user_r:user_t tcontext=user_u:user_r:user_t tclass=netlink_socket
Not sure what this is all about.
On Thu, 11 Mar 2004, Daniel J Walsh wrote:
Aleksey Nogin wrote: Is nsupdate a program to be run by an ordinary user? If yes we need to define a security context for nsupdate to allow it to access the netlink_sockets.
If we allow users access that any rogue app the user runs could access the network devices.
Btw, longer term, we will be implementing finer grained Netlink controls, so policy will be able to e.g. query the routing table but not update it.
- James
On 11.03.2004 13:18, Daniel J Walsh wrote:
Is nsupdate a program to be run by an ordinary user?
Yes. But if I understand correctly, it only needs to communicate over UDP or TCP to a DNS server from an unprivileged port. I do not know why it wants netlink_sockets.
If yes we need to define a security context for nsupdate to allow it to access the netlink_sockets.
Are you sure? _Why_ does nsupdate need it? Is it not an nsupdate deficiency?
Aleksey Nogin wrote:
On 11.03.2004 13:18, Daniel J Walsh wrote:
Is nsupdate a program to be run by an ordinary user?
Yes. But if I understand correctly, it only needs to communicate over UDP or TCP to a DNS server from an unprivileged port. I do not know why it wants netlink_sockets.
If yes we need to define a security context for nsupdate to allow it to access the netlink_sockets.
Are you sure? _Why_ does nsupdate need it? Is it not an nsupdate deficiency?
Taking a quick look at the code it is doing some stuff to determine if it has IPV4 and IPV6 support. You can define a security context for it and give it netlink access. If you take a look at the named.te file and copied the section on ncd_exec_t/ncd_t to nsupdate_exec_t/nsupdate_t you could get a good start on it. Then add
allow nsupdate_t self:netlink_socket create_socket_perms;
Dan
Aleksey Nogin wrote:
On 11.03.2004 13:18, Daniel J Walsh wrote:
Is nsupdate a program to be run by an ordinary user?
Yes. But if I understand correctly, it only needs to communicate over UDP or TCP to a DNS server from an unprivileged port. I do not know why it wants netlink_sockets.
If yes we need to define a security context for nsupdate to allow it to access the netlink_sockets.
Are you sure? _Why_ does nsupdate need it? Is it not an nsupdate deficiency?
Probably.
Daniel J Walsh wrote:
Aleksey Nogin wrote:
On 11.03.2004 13:18, Daniel J Walsh wrote:
Is nsupdate a program to be run by an ordinary user?
Yes. But if I understand correctly, it only needs to communicate over UDP or TCP to a DNS server from an unprivileged port. I do not know why it wants netlink_sockets.
If yes we need to define a security context for nsupdate to allow it to access the netlink_sockets.
Are you sure? _Why_ does nsupdate need it? Is it not an nsupdate deficiency?
nsupdate does the following which looks suspicious.
result = isc_net_probeipv4(); if (result == ISC_R_SUCCESS) have_ipv4 = ISC_TRUE;
How does one use nsupdate?
I just ran it and it came back with a
prompt.
Dan
Probably.
fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
On Tue, Apr 06, 2004 at 03:07:21PM -0400, Daniel J Walsh wrote:
nsupdate does the following which looks suspicious.
result = isc_net_probeipv4(); if (result == ISC_R_SUCCESS) have_ipv4 = ISC_TRUE;
That looks like it is trying to see if IPv4 is available.
How does one use nsupdate?
I just ran it and it came back with a
prompt.
You give it commands to remotely update the BIND nameserver zone, such as:
update add myhost.mydomain.com 86400 A a.b.c.d <--- blank line, very important!!! ^D
selinux@lists.fedoraproject.org
-
Aleksey Nogin -
Chuck Anderson -
Daniel J Walsh -
James Morris