Migrating to NetworkManager

[parfenovvs]

Is it possible to use NetworkManager for sudoless connection management and avoid wg-tools dependency?

[parfenovvs]

@claude Research this idea and update this issue with detailed plan, including pros and cons of such migration if it is possible. Also, think about alternatives.

[claude]

Claude finished @parfenovvs's task —— View job

---

Research: NetworkManager Migration Feasibility

I've completed comprehensive research on migrating MBVPN from wg-tools to NetworkManager for sudoless connection management, along with alternative approaches.

Current MBVPN Implementation Analysis

The current implementation in pkg/vpn/vpn.go:270-311 uses:

• wg-quick up/down commands requiring sudo for each operation
• Direct shell command execution via console.RunCmd(true, "wg-quick", ...)
• WireGuard config files stored in ~/.config/mbvpn/servers/*.conf
• Status checking via wg show command

NetworkManager Migration Assessment

Technical Feasibility: PARTIALLY VIABLE

NetworkManager cannot eliminate sudo requirements entirely, but can reduce them significantly through better permission management.

NetworkManager WireGuard Support

• Available since: NetworkManager 1.16.0 (March 2019)
• Production ready: NetworkManager 1.22.0+
• API: D-Bus interface at org.freedesktop.NetworkManager
• Configuration: Programmatic via D-Bus calls in Go using godbus library

Permission Model

• Current approach: Requires sudo for every connect/disconnect operation
• NetworkManager approach: Uses PolicyKit (polkit) for permission management
• User experience: Users in netdev group can manage VPN connections without password prompts
• One-time setup: Configure polkit rules instead of per-operation authentication

Pros and Cons

✅ Advantages of NetworkManager Migration

1. Reduced sudo friction: Configure once via PolicyKit vs per-operation sudo
2. Better desktop integration: Native network notifications and GUI compatibility
3. Improved connection lifecycle: NetworkManager handles interface management automatically
4. Enhanced DNS management: Automatic DNS configuration and leak prevention
5. System consistency: Integrates with system-wide network management

❌ Disadvantages and Limitations

1. Still requires elevated privileges: PolicyKit rules need configuration
2. NetworkManager dependency: Not available on all minimal Linux installations
3. Feature gaps: No PostUp/PreDown scripts, limited routing control vs wg-quick
4. Configuration complexity: D-Bus API is more complex than shell commands
5. Migration effort: Significant architectural changes required

Alternative Approaches Analysis

1. Capability-Based Security (CAP_NET_ADMIN) - ⭐ RECOMMENDED

• Approach: Set capabilities on mbvpn binary instead of using sudo
• Command: setcap cap_net_admin=ep /usr/local/bin/mbvpn
• Pros: Minimal code changes, immediate UX improvement, enhanced security
• Cons: Requires initial root setup, capability inheritance considerations
• Feasibility: HIGH - Most practical immediate solution

2. Direct netlink Socket Management

• Approach: Use Go libraries (vishvananda/netlink, wgctrl) for direct kernel communication
• Pros: Better error handling, more efficient than shell commands, existing library ecosystem
• Cons: Still requires CAP_NET_ADMIN, more complex implementation
• Feasibility: MEDIUM-HIGH - Good for long-term architecture evolution

3. systemd-networkd Integration

• Approach: Use systemd network files instead of wg-quick
• Pros: Native systemd integration, declarative configuration
• Cons: Limited to systemd systems, still requires elevated privileges
• Feasibility: MEDIUM - Would require significant refactoring

4. WireGuard Userspace Implementation

• Approach: Use wireguard-go instead of kernel module
• Pros: No kernel dependency, potentially fewer privileges required
• Cons: Performance penalty, still needs TUN device access
• Feasibility: MEDIUM - Performance tradeoffs

5. User Namespaces

• Approach: Create isolated network environments for unprivileged operation
• Pros: True unprivileged operation possible
• Cons: Very complex implementation, compatibility issues
• Feasibility: LOW - Too complex for practical implementation

Migration Plan Recommendation

Phase 1: Capability-Based Enhancement (Immediate - 1-2 weeks)

Goal: Eliminate sudo prompts while maintaining current architecture

Implementation:

1. Update installation scripts to set CAP_NET_ADMIN on mbvpn binary
2. Add capability detection with graceful fallback to sudo
3. Update documentation explaining the capability requirement

Benefits: Immediate UX improvement with minimal risk and code changes

Phase 2: Direct netlink Integration (Medium term - 4-6 weeks)

Goal: Replace shell commands with native Go network management

Implementation:

1. Replace wg-quick calls with vishvananda/netlink operations
2. Use existing wgctrl library for WireGuard configuration
3. Implement better error handling and status reporting
4. Maintain capability-based security model

Benefits: Better performance, error handling, and Go ecosystem integration

Phase 3: Optional NetworkManager Support (Long term - 8+ weeks)

Goal: Provide NetworkManager integration as an optional backend

Implementation:

1. Create pluggable backend architecture
2. Implement NetworkManager D-Bus backend alongside existing implementation
3. Add runtime detection and configuration option
4. Maintain backward compatibility with current approach

Benefits: Desktop integration for users who prefer NetworkManager

Conclusion

Recommendation: Implement Phase 1 (Capability-Based Security) immediately, as it provides the most practical solution to the sudoless operation requirement.

NetworkManager migration is technically possible but not the optimal solution due to:

• Complex implementation requirements
• Dependency on NetworkManager availability
• Limited additional benefits over capability-based approach
• Significant development effort for marginal improvements

The capability-based approach offers the best balance of:

• User experience improvement (no sudo prompts)
• Enhanced security (minimal privileges vs full root)
• Implementation simplicity (minimal code changes)
• Broad compatibility (works on all Linux distributions)

---

Generated with Claude Code