search for: cap_net_admin

Hi, we've seen SELinux reports from our users that dovecot tried to use something that needs CAP_NET_ADMIN capability. Before enabling it, we would like to know where it originated from. I've checked the sources, but was not able to find anything that would require this capability. Do you know for what it is used? CAP_NET_ADMIN Perform various network-related operations: * interface configuratio...

On 20 Jun 2017, at 14.18, Michal Hlavinka <mhlavink at redhat.com> wrote: > > Hi, > > we've seen SELinux reports from our users that dovecot tried to use something that needs CAP_NET_ADMIN capability. Before enabling it, we would like to know where it originated from. I've checked the sources, but was not able to find anything that would require this capability. Do you know for what it is used? Is this something that changed recently? Anyway, no idea. Do they have any more detai...

...ser space, >>> meaning to get to the kernel the packet has to first go thru >>> a virtio-net instance. >> >> yes. is that a sufficient filter in your opinion? > > Yes, the ability to create the device feels stronger than CAP_NET_RAW, > and a bit tangential to CAP_NET_ADMIN. But I don't have much practical > experience with virt so no strong opinion, perhaps it does make sense > for someone's deployment? Dunno.. > I'm not sure CAP_NET_ADMIN should be required for creating the VDUSE devices, as the device could be attached to vhost-vDPA and so no...

...ser space, >>> meaning to get to the kernel the packet has to first go thru >>> a virtio-net instance. >> >> yes. is that a sufficient filter in your opinion? > > Yes, the ability to create the device feels stronger than CAP_NET_RAW, > and a bit tangential to CAP_NET_ADMIN. But I don't have much practical > experience with virt so no strong opinion, perhaps it does make sense > for someone's deployment? Dunno.. > I'm not sure CAP_NET_ADMIN should be required for creating the VDUSE devices, as the device could be attached to vhost-vDPA and so no...

...get to the kernel the packet has to first go thru > > > > a virtio-net instance. > > > > > > yes. is that a sufficient filter in your opinion? > > > > Yes, the ability to create the device feels stronger than CAP_NET_RAW, > > and a bit tangential to CAP_NET_ADMIN. But I don't have much practical > > experience with virt so no strong opinion, perhaps it does make sense > > for someone's deployment? Dunno.. > > > > I'm not sure CAP_NET_ADMIN should be required for creating the VDUSE > devices, as the device could be at...

...ernel the packet has to first go thru >>>>> a virtio-net instance. >>>> >>>> yes. is that a sufficient filter in your opinion? >>> >>> Yes, the ability to create the device feels stronger than CAP_NET_RAW, >>> and a bit tangential to CAP_NET_ADMIN. But I don't have much practical >>> experience with virt so no strong opinion, perhaps it does make sense >>> for someone's deployment? Dunno.. >>> >> >> I'm not sure CAP_NET_ADMIN should be required for creating the VDUSE >> devices, as the...

...n not permitted 2015-03-02T18:00:51.243518Z qemu-kvm: -netdev tap,script=/tmp/vnet380622.sh,id=hostnet1: Device 'tap' could not be initialized They can be resolved like this: 1) Edit /etc/libvirt/qemu.conf, and add "/dev/net/tun" to the cgroup_device_acl option 2) Run: setcap cap_net_admin+eip /bin/qemu-system-x86_64 This will give QEMU CAP_NET_ADMIN when it runs. Make sure you review `man capabilities` to see what capabilities this actually gets qemu. The downside here is that in the event a guest somehow breaks out of qemu, CAP_NET_ADMIN gives them a bunch of scary permissions...

...(fd, > > > TUNSETIFF,...)` in it. AFAIK, both of those operations *require* the > > > NET_ADMIN capability. If I'm correct, this means that the current > > > libvirt implementation makes our goals impossible to achieve. > > > > AFAIK, that is not correct - CAP_NET_ADMIN isn't required to open > > or create a tap device - only to add the tap device to a bridge. > > > > So if you create the tap device & attach it to a bridge ahead of > > time, libvirt should then be able to open it and give it to QEMU > > https://git.kernel.org/...

...net_bridge *br = netdev_priv(dev); + unsigned long args[4]; + + if (cmd != SIOCDEVPRIVATE) + return -EOPNOTSUPP; + + if (copy_from_user(args, rq->ifr_data, sizeof(args))) + return -EFAULT; + + switch (args[0]) { case BRCTL_ADD_IF: case BRCTL_DEL_IF: { @@ -44,11 +73,11 @@ if (!capable(CAP_NET_ADMIN)) return -EPERM; - dev = dev_get_by_index(arg0); + dev = dev_get_by_index(args[1]); if (dev == NULL) return -EINVAL; - if (cmd == BRCTL_ADD_IF) + if (args[0] == BRCTL_ADD_IF) ret = br_add_if(br, dev); else ret = br_del_if(br, dev); @@ -83,7 +112,7 @@ b.gc_timer_valu...

...3518Z qemu-kvm: -netdev > tap,script=/tmp/vnet380622.sh,id=hostnet1: Device 'tap' could not be > initialized > > They can be resolved like this: > > 1) Edit /etc/libvirt/qemu.conf, and add "/dev/net/tun" to the > cgroup_device_acl option > 2) Run: setcap cap_net_admin+eip /bin/qemu-system-x86_64 > > This will give QEMU CAP_NET_ADMIN when it runs. Make sure you review > `man capabilities` to see what capabilities this actually gets qemu. > > The downside here is that in the event a guest somehow breaks out of > qemu, CAP_NET_ADMIN gives them...

...10 -07:00 +++ b/net/bridge/br_ioctl.c 2004-05-20 14:46:10 -07:00 @@ -78,13 +78,36 @@ return num; } -int br_dev_ioctl(struct net_device *dev, struct ifreq *rq, int cmd) +static int add_del_if(struct net_bridge *br, int ifindex, int isadd) +{ + struct net_device *dev; + int ret; + + if (!capable(CAP_NET_ADMIN)) + return -EPERM; + + dev = dev_get_by_index(ifindex); + if (dev == NULL) + return -EINVAL; + + if (isadd) + ret = br_add_if(br, dev); + else + ret = br_del_if(br, dev); + + dev_put(dev); + return ret; +} + +/* + * Legacy ioctl's through SIOCDEVPRIVATE + * This interface is deprecated bec...

...e clone device (/dev/net/tun), and calling `ioctl(fd, > TUNSETIFF,...)` in it. AFAIK, both of those operations *require* the > NET_ADMIN capability. If I'm correct, this means that the current > libvirt implementation makes our goals impossible to achieve. AFAIK, that is not correct - CAP_NET_ADMIN isn't required to open or create a tap device - only to add the tap device to a bridge. So if you create the tap device & attach it to a bridge ahead of time, libvirt should then be able to open it and give it to QEMU Regards, Daniel -- |: https://berrange.com -o- https://www.fl...

On Tue, 30 Apr 2019 at 10:40, Michal Privoznik <mprivozn@redhat.com> wrote: > Is there any problem running libvirtd as root? > > Yes, in the regulated environment in which I work! I have to do far more thorough threat analysis than I would do if I knew which capabilities it had. So far, we've accepted the extra work; but it would be wonderful to be able to run a locked-down

....h> +#include <linux/rtnetlink.h> #include <asm/uaccess.h> #include "br_private.h" @@ -230,11 +231,8 @@ return -EOPNOTSUPP; } -static DECLARE_MUTEX(ioctl_mutex); - int br_ioctl_deviceless_stub(unsigned long arg) { - int err; unsigned long i[3]; if (!capable(CAP_NET_ADMIN)) @@ -243,11 +241,8 @@ if (copy_from_user(i, (void *)arg, 3*sizeof(unsigned long))) return -EFAULT; - down(&ioctl_mutex); - err = br_ioctl_deviceless(i[0], i[1], i[2]); - up(&ioctl_mutex); - - return err; + ASSERT_RTNL(); + return br_ioctl_deviceless(i[0], i[1], i[2]); } int br_...

Hello, I need CAP_FOWNER=ep for the asterisk process, i set it with setcap on the file /usr/sbin/asterisk, it's there when i look on it with getcap, but after starting and loocking with getpcaps there's only cap_net_admin+ep set. So how exactly do I set CAP_FOWNER? Do I have to patch and recompile or is there another solution I did not see yet? thanks, best -- Raimund Sacherer - RunSolutions Open Source It Consulting - Parc Bit - Centro Empresarial Son Espanyol Edificio Estel - Local 3D 07121 - Palma de...

...a wireless nic. > > Just do the network configuration inside the vm, and the routing, well > on your router? You will just need the route for the vm networks on your > host, but what is your attack scenario to keep this separated from other > routes on this host? you need at least CAP_NET_ADMIN to fiddle with those. How? If the same host routes Internet traffic in the main routing table I expose host's services to Internet. > > -- > Mit freundlichen Gr??en / Regards > > Sven Kieske > > Systemadministrator > Mittwald CM Service GmbH & Co. KG > K?nig...

This patch adds a 'hairpin' (also called 'reflective relay') mode port configuration to the Linux Ethernet bridge kernel module. A bridge supporting hairpin forwarding mode can send frames back out through the port the frame was received on. Hairpin mode is required to support basic VEPA (Virtual Ethernet Port Aggregator) capabilities. You can find additional information on VEPA

This patch adds a 'hairpin' (also called 'reflective relay') mode port configuration to the Linux Ethernet bridge kernel module. A bridge supporting hairpin forwarding mode can send frames back out through the port the frame was received on. Hairpin mode is required to support basic VEPA (Virtual Ethernet Port Aggregator) capabilities. You can find additional information on VEPA

This patch adds a 'hairpin' (also called 'reflective relay') mode port configuration to the Linux Ethernet bridge kernel module. A bridge supporting hairpin forwarding mode can send frames back out through the port the frame was received on. Hairpin mode is required to support basic VEPA (Virtual Ethernet Port Aggregator) capabilities. You can find additional information on VEPA

...f-exists del-port) unexpected > exit status 1: ovs-vsctl: 'del-port' command requires at least 1 > arguments > Mar 06 14:04:46 selfip.ru libvirtd[6418]: Unable to delete port (null) > from OVS: Operation not permitted I assume that any admin commands related to OVS will require CAP_NET_ADMIN as is required for all non-OVS network tasks too, which pretty much means you have to be root. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/:| |: http://libvirt.org -o- http://virt-manager.org:| |: http://autobuild.org...