[opensuse] Linux desktop and enterprise virus and such security
I have been trying to get my openSUSE desktops to play nice in our company's increasingly draconian security system. Every time I think I have made progress, there is another obstacle. Case in point. Our company has decided that Cisco will be the security provider. This includes using Cisco routers and Cisco software. In software, they are using Cicso's ICE, Umbrella, and AMP. I have been working with IT to see how our openSUSE desktops can play along with this. Things looked hopeful. Until they provided me with the AMP package. It is a RPM designed for use on Red Hat systems. Of course, I had a peek around to see what was really Red Hat specific. With a hope that it was standard and could be run on openSUSE. So close. But there were two obstacles: 1. It likes to keep the virus database up-to-date. That is, of course, needed. Unfortunately, it uses a very old RPM version/library to manage installed packages. That version is not compatible with the newer version openSUSE uses. I think it could be possible to get around that. Not sure. But maybe. 2. It installs some drivers. This requires that the drivers match the operating system version. AMP only supports a very old kernel (3.10.0 in RHEL 7, which Red Hat seems to patch with security fixes). This is unfortunate. And it need not be done this way (NVIDIA also installs drivers - but their method supports more OS versions by install-time linking of modules for the current kernel). This is the show stopper. I see no way to get around this incompatibility. Also RHEL is not really a desktop release. It was originally released in Oct of 2015. I have no interest in working in an old desktop. I guess I don't have a real question. Other than why Linux is still being marginalized by major companies? Surely I'm not the only user in a corporate environment where the security tools are mandated company-wide. It's not enough to claim that you have installed something at least equivalent. They only trust what they have selected. AMP, as it turns out, seems to use ClamAV. But it adds an interface that allows corporate monitoring that all is working as expected. With almost 40000 people, I cannot blame the security guys for wanting this kind of information. I guess it would take convincing from companies like SUSE (or a consortium of Linux companies working as a single entity) to get Cisco to consider proper Linux desktop support (maintained by Cisco in their own OBS environment to allow packages for multiple distros?). The humorous thing is that with Red Hat's acquisition by IBM, I think IBM's security stuff will be the preferred solution for Red Hat users. Cisco will surely see a decrease in Red Hat sales. And from that decide that Linux is not worth the effort. Some days I just feel too old for all this... -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/11/19 11:39 AM, Roger Oberholtzer wrote:
to play nice in our company's increasingly draconian security system
fantasy section : would it be poss. to run VirtMach on Cisco-base : all yr current stuff on VM .... regards -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Nov 11, 2019 at 11:13 AM ellanios82 <ellanios82@gmail.com> wrote:
On 11/11/19 11:39 AM, Roger Oberholtzer wrote:
to play nice in our company's increasingly draconian security system
fantasy section : would it be poss. to run VirtMach on Cisco-base : all yr current stuff on VM
That is exactly what we are planning. Run Tumbleweed in a VirtualBox or some such, hosted on a Windows 10 box running the Cisco stuff. The shared drives we want to access (can can only access if the Cisco stuff is in place) are made available to the VM by the Windows host. At least I hoe it will be allowed to do that. I can't say that I relish the idea of working 100% in a VM hosted on Windows. But desperate times call for desperate measures. There are a couple of scenarios that this will not solve: 1. We have some Linux machines doing continuous (24/7) data delivery via a REST protocol. On Windows, this runs very much slower than it does on Linux. So we have been running this on Linux. It is unclear why it is so much slower on Window. It is the same code. Or as much so as these things can ever be on different platforms - our part is the exact same. The solution here will be to go back to using Windows, taking the speed penalty. Perhaps they will need to add more systems to make up the speed penalty. 2. We have a subversion/Trac/Jenkins system that runs on Tumbleweed. We are seriously thinking of moving it to an external server. Or better yet find an external place to locate our server. We want external access to this as well as internal access. The IT guys could provide the external access. But no internal access if it is not running the Cisco stuff. We have played with other ideas. But they all had their own set of problems. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dne pondělí 11. listopadu 2019 11:50:27 CET, Roger Oberholtzer napsal(a):
On Mon, Nov 11, 2019 at 11:13 AM ellanios82 wrote:
On 11/11/19 11:39 AM, Roger Oberholtzer wrote:
to play nice in our company's increasingly draconian security system
fantasy section : would it be poss. to run VirtMach on Cisco-base: all yr current stuff on VM
That is exactly what we are planning. Run Tumbleweed in a VirtualBox or some such, hosted on a Windows 10 box running the Cisco stuff. The shared drives we want to access (can can only access if the Cisco stuff is in place) are made available to the VM by the Windows host. At least I hoe it will be allowed to do that. I can't say that I relish the idea of working 100% in a VM hosted on Windows. But desperate times call for desperate measures. There are a couple of scenarios that this will not solve: 1. We have some Linux machines doing continuous (24/7) data delivery via a REST protocol. On Windows, this runs very much slower than it does on Linux. So we have been running this on Linux. It is unclear why it is so much slower on Window. It is the same code. Or as much so as these things can ever be on different platforms - our part is the exact same. The solution here will be to go back to using Windows, taking the speed penalty. Perhaps they will need to add more systems to make up the speed penalty. 2. We have a subversion/Trac/Jenkins system that runs on Tumbleweed. We are seriously thinking of moving it to an external server. Or better yet find an external place to locate our server. We want external access to this as well as internal access. The IT guys could provide the external access. But no internal access if it is not running the Cisco stuff.
3. You are effectively bypassing the security as the system hosted in the VM can't be effectively controlled by the Cisco tools while it has full access to the local network. IMHO security IT guys will be complaining about this. -- Vojtěch Zeisek Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/ https://trapa.cz/
On Mon, Nov 11, 2019 at 12:06 PM Vojtěch Zeisek <vojtech.zeisek@opensuse.org> wrote:
3. You are effectively bypassing the security as the system hosted in the VM can't be effectively controlled by the Cisco tools while it has full access to the local network. IMHO security IT guys will be complaining about this.
I don't think so. All access to anything is tied to the MAC address of the client (via Cisco ICE). The Windows host running all the Cisco stuff will be granted access via ICE. It will be the one mounting the drives. The VM it runs will not mount the drives from the server. They are shared with the VM by VirtualBox running on the host that actually reads/writes them. I do need to check that VB can do this with remote drives. I know that there can be issues. Not so much security but with sharing a remote drive in general. It is not sharing it on the network. It is shared with the VB program. Much like the files can be accessed by any other program running on the host. The Windows host will share this drive with the Linux client. In that sense it is no different that any other program accessing the drive. Ultimately it goes through Windows and thus whatever Windows security there is on the drive access. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/11/2019 03:39 AM, Roger Oberholtzer wrote:
Some days I just feel too old for all this...
I feel your pain.... It's a follow the $ issue. RH, etc. make theirs from servers. Servers hardware hasn't really changed to require any of the new kernel features in ages. They have a bullet-proof kernel and can validate/backport any security or new hardware features needed at lot easier that certifying that all the kernel code added between 3.10 and 5.3 (by thousands of different individuals) doesn't contain any unforeseen security flaw. If you can't get a srpm for the AMP package, then I guess the best you can do is just find out what in AMP isn't compatible and see if you can work around it -- it may be as simple as a symlink. The only downside is the time it takes to chase the issue down. It may also be worth a call to the tech folks that provide AMP to see if they have a version compatible with later kernels... Otherwise, I'm sure you can get used to typing "dir" instead of "ls" :) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 11/11/2019 à 16:05, David C. Rankin a écrit :
code added between 3.10 and 5.3
my not so old android phone use 3.18. May be a very good kernel :-)) jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/11/2019 09:11 AM, jdd@dodin.org wrote:
Le 11/11/2019 à 16:05, David C. Rankin a écrit :
code added between 3.10 and 5.3
my not so old android phone use 3.18. May be a very good kernel :-))
jdd
There is nothing wrong with old kernels so long as your hardware doesn't need anything that was added later. Look at RH, Debian, Slackware, etc... All have older kernels, and the do fine. All of my boxes, except maybe the laptop would do fine on 3X kernels. I don't have bleeding-edge gadgets. The key for any old kernel is that they are patched for any of the security issues that have been found since their original release and now. That's basically what openSUSE and SuSE do as well. Yes, the 5.3 kernel is out, but openSUSE is on 4.12. The 4.4 used with 42.3 did everything I needed (and it still had the version of valgrind that accurately reported user allocated memory and excluded what stdio used) Unless you have bleeding-edge hardware that requires new module X from kernel Y, a newer kernel will provide little to no benefit. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Nov 11, 2019 at 4:55 PM David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
There is nothing wrong with old kernels so long as your hardware doesn't need anything that was added later. Look at RH, Debian, Slackware, etc... All have older kernels, and the do fine. All of my boxes, except maybe the laptop would do fine on 3X kernels. I don't have bleeding-edge gadgets.
I agree that for a server this is okay. But we are talking about desktops. One is on a new Dell XPS laptop. Other system are on equally new hardware. We are (finally) moving in to using GPUs in our image processing. I cannot see myself really using RHEL 7 as a serious desktop environment. I'm adventurous. I'm not insane...
Unless you have bleeding-edge hardware that requires new module X from kernel Y, a newer kernel will provide little to no benefit.
Bingo -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/11/2019 01:39 AM, Roger Oberholtzer wrote:
I guess I don't have a real question. Other than why Linux is still being marginalized by major companies? Surely I'm not the only user in a corporate environment where the security tools are mandated company-wide. It's not enough to claim that you have installed something at least equivalent. They only trust what they have selected. AMP, as it turns out, seems to use ClamAV. But it adds an interface that allows corporate monitoring that all is working as expected. With almost 40000 people, I cannot blame the security guys for wanting this kind of information.
I've got a similar problem, Roger. My customer insists on using a security system which is nothing but a huge root-kit that frequently renders even Windows systems unusable. This system is supported for SLES and openSUSE systems, but the vendor is usually a release behind the current openSUSE version. So I've had luck in carving out an exception for my two-dozen openSUSE boxes by keeping them current and claiming that the security system doesn't support my running versions. The customer could, of course, mandate which operating systems they will allow on their networks, but that hasn't happened yet. I've been dodging this bullet for more than a decade, thanks to openSUSE! At one point they were insisting on using SELinux, but I located a study that showed that while SELinux is very capable, it's also very hard to configure and get working right. While AppArmor may not be as complete a solution, it does give net better security because it's easier to configure and operate. I haven't actually had to use this justification yet, but I've got it ready to roll out just in case.
Some days I just feel too old for all this...
I feel your pain. Just think of the information assurance bureaucracy as a challenge and an opportunity to do creative work to keep your users productive. BTW, has your customer ever experienced a security incident on a Linux box? I had one about 18-years ago, but caught it right away. The vulnerability was a problem with the old ssh 1.2 daemon. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (6)
-
David C. Rankin -
ellanios82 -
jdd＠dodin.org -
Lew Wolfgang -
Roger Oberholtzer -
Vojtěch Zeisek