Podcasts about seccomp

Sponsor by SEC Playground แบบสอบถามเพื่อปรับปรุง Chill Chill Security Channel: https://forms.gle/e5K396JAox2rZFp19 Music by https://www.bensound.com/ --- Support this podcast: https://anchor.fm/chillchillsecurity/support

It’s Kubernetes release day! The team that launched v1.22 of everyone’s favourite cluster management software was led by Savitha Raghunathan, Senior Platform Engineer at MathWorks. Savitha joins host Craig Box to talk contribution, containers and cricket. Do you have something cool to share? Some questions? Let us know: web: kubernetespodcast.com mail: kubernetespodcast@google.com twitter: @kubernetespod Chatter of the week Life before smartphones Dark Sky, hyperlocal weather app Karl the Fog Universal Studios Kubeyland 2021 The Simpsons Ride News of the week Kubernetes 1.22 announcement Sign up for the 1.23 release team Linkerd graduates* in the CNCF Cosign 1.0 Episode 152, guest host Dan Lorenc Episode 155, with Priya Wadwha Cloud Native Rejekts CFP Episode 79, with Chris Kühl Introducing Koncrete by the Kalm team Nestybox adds Kubernetes support Curiefense adds NGINX support Replicated announces $50M Series C Episode 143, with Grant Miller Kubernetes platform updates: Deckhouse, by Flant, is GA Red Hat OpenShift 4.8 Rafay adds new features to Kubernetes Management Cloud Carvel Package Manager for Kubernetes Porter and seed funding announcement Links from the interview Chennai Super Kings Stephen Fleming; coach, A/C salesman and Yellow Wiggle Royal Challengers Bangalore MathWorks MATLAB Math vs maths? (Doesn’t actually matter; MATLAB is short for Matrix Laboratory) Savitha’s first contribution Kubernetes GitHub workflow and pull request guide Kubernetes 1.22 release announcement Release Team Loki and WandaVision Enhancements of note: Seccomp by default Rootless Kubelet Pod admission control Node swap support Windows privileged containers 1.21 release interview with Nabarun Pal Do, Delegate and Defer Release lead for 1.23: Rey Lejano In memoriam: Peeyush Gupta Donate to Peeyush’s Family Education Fund Coffee art Amigurumi Savitha’s cat Savitha Raghunathan on Twitter

Les conteneurs nous permettent plus que jamais d'accélérer le déploiement de nos applications. Elles sont désormais portables, prêtes à l'emploi et il est possible d'en exécuter des centaines, voire des milliers, sur une même machine. Mais il y a un revers à la médaille : comment être sûr qu'une application n'exécute que le code pour lequel elle est conçue ? Comment repérer un shell malicieux lancé par un tier ? Plus la densité de conteneurs sur un noeud augmente, et plus cette tâche pourrait sembler se complexifier.Bien sûr, il existe depuis longtemps des outils pour nous protéger, comme SELinux, AppArmor ou Seccomp. Ils ne nous mettent pourtant pas à l'abri d'une règle mal écrite ou trop laxiste. Alors comment s'assurer que la règle définie ne contiennent pas de faille qui permette de s'en échapper ? La réponse semble évidente : par l'audit nos systèmes. Et Falco est justement un outil nous permettant de nous acquitter facilement de cette tâche.Dans cet épisode, je reçois Thomas Labarussias. Thomas est Site Reliability Engineer pour Qonto, mais il est avant tout le mainteneur de Falco Sidekick. Avec lui, je discute de Falco et de ce qu'il apporte en terme de sécurité à nos applications, mais aussi de Sidekick, de ses cas d'usage, et des raisons qui ont poussé Thomas à s'investir dans un tel projet.Notes de l'épisodeCaptations et les compte-rendus de la communauté de Falco : https://github.com/falcosecurity/communitySupport the show (https://www.patreon.com/electromonkeys)

10 minutes for you to be aware of the latest events of Kubernetes world from the virtual conference KubeCon Europe 2020Guest: Ihor Dvoretskyi CNCFCloud Native MeditationCNCF ReportK8S Product Update01:34 Furry Friends https://explore.org/livecams/kitten-rescue/kitten-rescue-cam03:00 The State of Cloud Native Development https://rb.gy/jicctk04:20 Ihor Dvoretskyi https://www.linkedin.com/in/idvoretskyi17:38 What's New in Kubernetes 1.19 https://rb.gy/jtc1ue18:39 Seccomp https://rb.gy/hzez5w18:53 Kubernetes security assessment TKS 1.3 https://rb.gy/su7uyu19:02 Node debugging https://rb.gy/kpkyot20:13 Immutable ConfigMaps and Secrets https://rb.gy/u4wrjn20:52 Sidecar Containers https://rb.gy/4uxwzw21:07 Replace whitelist to allowlist https://rb.gy/7dleeq

WISP.org PSA at 35m56s - 37m 19s   Agenda:Bio/background Why are you here (topic discussion) What is the Linux Security Summit North America https://grsecurity.net/   Questions from the meeting invite:   This only affects people who want to use a custom kernel, correct? This doesn’t affect you if you are running bog-standard linux (debian, gentoo, Ubuntu) right? What options do people have in cloud environments?   Does the use of microservices make grsecurity less worthwhile?   You mentioned ARM 64 processors in your first slide as making  significant security functionality strides. With Apple and Microsoft going to ARM based processors, what are some things you feel need to be added to the kernel to shore up Linux for ARM, since some purists enjoy an Apple device with Linux on it? https://www.youtube.com/watch?v=F_Kza6fdkSU - Youtube Video   https://grsecurity.net/10_years_of_linux_security.pdf -- pdf slides   https://lwn.net/Articles/569635/ - Definition of KASLR    LTS kernels moved from 2 years to 6 years - why? 6 years is pretty much “FOREVER” in software development.  Patches get harder to backport, or worse; Could introduce new vulnerabilities Project Treble: https://www.computerworld.com/article/3306443/what-is-project-treble-android-upgrade-fix-explained.html   LTSI: https://ltsi.linuxfoundation.org/   4.4 XLTS is available until Feb2022 -  If fixes and all bugs haven’t been backported (1,250 security fixes aren’t in the latest stable 4.4 kernel) What are the “safe” kernels? Has anything changed since the presentation you gave earlier in July 2020    Syzkaller Let’s discuss Slide 27 (what are those tems?) “Is it improving code quality, or Is it making people lazier and more reliant on a tool to check code?” Slide 29 audio, you mention that you use Syzkaller… why do you use it?   Exploitation Trends Attackers still don’t care about whether a vulnerability has a CVE assigned or not Don’t many vulnerabilities require some work to get to the kernel? And why should they work to get to the kernel?   https://www.bleepingcomputer.com/news/security/rewards-of-up-to-500-000-offered-for-freebsd-openbsd-netbsd-linux-zero-days/ 500K IF the kernel vuln affects major distros (Centos, Ubuntu) https://resources.whitesourcesoftware.com/blog-whitesource/top-10-linux-kernel-vulnerabilities   Why does Zerodium payout for kernel vulns lower than application vulns? Would it be fair to say that getting root/persistence is all that matters and you don’t need to worry about the kernel to do so?   Many of the new security features are protecting against bad programming practices?  So by adding all these things, who are you securing systems against?  Bad actors, or devs who employ poor coding measures?  Why do you think we see lower adoption rates of security      Problem solving: Halvar Flake: http://addxorrol.blogspot.com/2020/03/before-you-ship-security-mitigation.html   If we have time…    Threat models in a kernel Where do they go in the development lifecycle? If kernel dev is an open environment, what precipitates the need for a kernel mitigation threat model Is there an example somewhere that we can see? What is the format? Methodology? Do you think static code analysis of the kernel is worthwhile at all? Absolutely! We do a lot of it, including via the analysis resulting from compiling with LLVM, as well as via specific static analysis GCC plugins of our own.   OK, what about the large amount of false positives the analyzers generate? Do you get around with your custom plugins? Also do you use the analyzers included with Clang and GCC v.10 or 3rd products? That's usually a property of the analysis itself -- some can have large false positive issues, others not. Ideally we try to limit that for the plugins we write (we just recently added one helpful for some kind of NULL ptr dereferences this week). My understanding is the public now also has access to the Coverity reports for the kernel? As far as GCC versions, yes we test with all versions from 4.5 to 10.   What do you think of proposed XPFO patch? https://lwn.net/Articles/784839/ The performance profile is a big problem, and it doesn't address that the same attack can be performed in a different way that it wouldn't handle (that limitation is also mentioned in the original paper). So we haven't invested in it at all with our own work.   how about git sha-256 security measures ? Not my domain of expertise, but sounds like a good idea.   What is the status of KASLR on non-Intel architectures? ARMv7/v8? It exists there as well, and is shipped in Android. It's also recently been added for PowerPC.   What dynamic analysis/testing tools do you use for the kernel? We have a couple racks of hardware, including some new AMD EPYC2 systems dedicated entirely to testing and syzkaller fuzzing. We have syzkaller in place (along with backports of functionality to improve its functionality/coverage) for all kernels we support, as well as a good mix of physical/VM systems for major distros, and automated build/boot/functionality/regression testing in a number of configs across ARM/ARM64/MIPS/PowerPC/SPARC64/i386/x86_64. Thanks! Do you write your own configs/definitions for syzkaller? Yes, including some changes to the code to have it detect some of our specific kernel message (size_overflow, refcount, RAP, etc)   What do you think about LKRG? Also, does grsec provide any similar runtime protection/detection/security? I think it's a good alternative to some other commercial security products, but it's not what our goal is with grsecurity. I like the author of LKRG, but heuristic-based security is always problematic as you can't perform the checks everywhere they need to be performed, or as often as they need to be performed. When an attacker knows the checks performed (or has a general idea), then it's easy to devise an attack that would bypass it, knowing how computationally complex it would be to detect. So in grsecurity we focus on providing real defense vs just having a chance to detect something after the fact.   Do you plan on implementing RAP on PowerPC Architecture? We haven't seen any commercial interest in it, but RAP is technically architecture-independent. We've done some demos for non-x86 architectures, and also just recently (within the past month or so), released a version for i386.   For how long GRSecurity is planning to support 5.4 LTS and LTS generally? What do you think is a good rule of thumb? We've always generally supported them for 3 years, regardless of upstream's support periods. We have an independent process for performing backports that involves looking at all the upstream commits and other sources of information, regardless of any stable/Fixes tags (basically a manual version of AUTOSEL).   What is your opinion of the recently proposed Function-Granular KASLR series? Not a fan of *KASLR in the kernel in general. It tries to deal with a problem (poorly) that there already exists a much better solution for: CFI.   Could you comment on how well (relative to your x86 detailed knownledge) ARM and PPC security fixes are backported? We have many years of reverse engineering experience (15+ on my end) across multiple architectures. We were the first to develop software-based PXN/PAN for ARM for instance. We've also developed functionality specifically for non-x86 architectures. Within the past 2 years or so, we added POWER9 support for REFCOUNT, and have the physical hardware on site (in additional to qemu-based testing) to perform the work. But yes, our backports cover all architectures we support.   What is your opinion on the use of BPF for security-purposes, i.e. security monitoring and newer approaches like KRSI? Enabling something like BPF solely for the use of security seems like it could backfire, given how invasive it is. As long as it's not controllable by an unprivileged user, I think it's fine. Anything that avoids the hassle of having to upstream something in order to implement some new kind of security check, is a good idea. They'll still be limited by the LSM interface itself, so that would be the next barrier to go. With BTF, there's a lot of possibility there.   Regarding exploiting containers: isn't the issue with containers that they have very poor defaults and that people don't use the features they could? For example: mounting sysfs or procfs into a container or not adjusting seccomp/apparmor (or better(?) selinux) policies? That's a problem, but the crucial problem is the shared kernel among all containers. If you look at past exploits, they've been in things like futex, mremap, waitid, brk, etc, all syscalls that would be allowed in nearly all of the most strict seccomp policies. The granularity of current seccomp policies is really not that great, and any sufficiently complex code will necessarily have exposure to a large part of kernel attack surface.   What do you think about the CIP Projects' focus on CVE tracking (especially for the kernel)? It's a good initiative, but the main problem with the kernel is that most vulnerabilities in the kernel don't get a CVE in the first place. I know for certain that many of the security issues we've tweeted haven't had a CVE assigned. The ones that do are when a distro with the vuln present in their kernel spots it and requests one. Most vulnerabilities in recent kernels especially don't get CVEs requested, because distros aren't shipping them.   What's your opinion on SMACK? Any other reference implementation except Tizen? Haven't used it myself, so no opinion one way or another, sorry Doesn't seem bad at least in terms of number of security fixes backported to it compared to other access control LSMs.   If you disable as many CONFIG_* options in your kernel config have you actually reduced your attack surface or is most of the vulnerable code not in modules? Yes, this is a good approach particularly for upstream kernels. I would definitely recommend compiling your own kernel instead of using default distro configs (from a security perspective). Under grsecurity, we have a feature that makes it actually a good idea to put as much functionality in modules as possible, as they can't be auto-loaded by unprivileged users. So the functionality is there if it's needed across a fleet of systems, without the downsides. TARA analysis performed in Linux Kernel ? I'm not familiar with this, sorry!   Is the poor state of LTS and XLTS security backports found in PPC and ARM as well as (presumably) what you report for x86? It's somewhat of an across-the-board problem   Actually I hoped that you will tell about new cool features that appeared in grsecury. Can you share anything about your new kernel heap hardening? It's called AUTOSLAB, and it's useful both for security (particularly against AEG and UAFs), but also for debugging.  Minimal performance impact, we've had one person mention their system feels faster now, and we actually had a bug in one of our routine benchmarks where the feature got enabled in the "minimal" config, yet still reported better benchmark results in all tests than an upstream kernel.  So a really nice performance profile, with some additional memory wastage in the MEMCG case, but nothing terrible.  Also non-invasive, as it's done through a GCC plugin. Thanks for your talk, Brad! What would make you work for upstream? We offered that already years ago, and none of the companies involved seemed to be interested.  So we're funded directly now by people that benefit from our work.       Check out our Store on Teepub! https://brakesec.com/store Join us on our #Slack Channel! Send a request to @brakesec on Twitter or email bds.podcast@gmail.com #AmazonSmile: https://brakesec.com/smile  #Brakesec Store!:https://www.teepublic.com/user/bdspodcast #Spotify: https://brakesec.com/spotifyBDS #Pandora: https://pandora.app.link/p9AvwdTpT3 #RSS: https://brakesec.com/BrakesecRSS #Youtube Channel:  http://www.youtube.com/c/BDSPodcast #iTunes Store Link: https://brakesec.com/BDSiTunes #Google Play Store: https://brakesec.com/BDS-GooglePlay Our main site:  https://brakesec.com/bdswebsite #iHeartRadio App:  https://brakesec.com/iHeartBrakesec #SoundCloud: https://brakesec.com/SoundcloudBrakesec Comments, Questions, Feedback: bds.podcast@gmail.com Support Brakeing Down Security Podcast by using our #Paypal: https://brakesec.com/PaypalBDS OR our #Patreon https://brakesec.com/BDSPatreon #Twitter: @brakesec @boettcherpwned @bryanbrake @infosystir #Player.FM : https://brakesec.com/BDS-PlayerFM #Stitcher Network: https://brakesec.com/BrakeSecStitcher #TuneIn Radio App: https://brakesec.com/TuneInBrakesec

From the low-end to the high-end we try out both ends of the Linux hardware spectrum. Wes reviews the latest XPS 13, and Chris shares his thoughts on the Pinebook Pro. Plus a really cool new feature in Linux 5.7, and we get some answers to the recent GNOME patent settlement from the source. Special Guests: Dan Johansen and Drew DeVore.

# Podcast S01-E28: KubeCon EU 2020 y Google Next virtuales - Conducido por @_marKox, @domix ## Revisión de las noticias - [KubeCon & CloudNativeCon Europe 2020 Virtual](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/) - [New from Satellite 2020: GitHub Discussions, Codespaces, securing code in private repositories, and more](https://github.blog/2020-05-06-new-from-satellite-2020-github-codespaces-github-discussions-securing-code-in-private-repositories-and-more/) ## Referencias y Recursos - [Analyzing Docker Image Security](https://martinheinz.dev/blog/19) - [Rolling Update Deployment Strategy in Kubernetes](https://medium.com/faun/rolling-update-deployment-strategy-in-kubernetes-25e5b1566dd3) - [Seccomp in Kubernetes — Part I: 7 things you should know before you even start!](https://itnext.io/seccomp-in-kubernetes-part-i-7-things-you-should-know-before-you-even-start-97502ad6b6d6) - [What is Service Mesh?](https://www.solo.io/solutions/service-mesh/) - [Deploy AWS EKS Fargate Cluster](https://medium.com/@sabyasachibhattacharya/deploy-aws-eks-fargate-cluster-beb2f6d3583d) - [DevNation Master Course](https://developers.redhat.com/devnation/master-course/) ## Repos chingones de código - [A static type analyzer for Python code](https://github.com/google/pytype) ## Eventos - [Google Next OnAir](https://cloud.withgoogle.com/next/sf) ### Créditos de música Music by Scott Buckley – www.scottbuckley.com.au

We explain what eBPF is, how it works, and its proud BSD production legacy. eBPF is a technology that you’re going to be hearing more and more about. It powers low-overhead custom analysis tools, handles network security in a containerized world, and powers tools you use every day.

    Container security   Jay Beale  @inguardians , @jaybeale   Containers What the heck is a container? Linux distribution with a kernel Containers run on top of that, sharing the kernel, but not the filesystem Namespaces Mount Network Hostname PID IPC Users Somebody said we’ve had containers since before Docker Containers started in 2005, with OpenVZ Docker was 2013, Kubernetes 2014 Image Security CoreOS Clair for vuln scanning images Public repos vs private Don’t keep the image running for so long? Don’t run as root More Containment stuff Non-privileged containers Remap the users, so root in container isn’t root outside Drop root capabilities Seccomp for kernel syscalls AppArmor or SELinux All of above is about Docker, what about Kubernetes Get onto most recent version of K8S - 1.7 and 1.8 brought big security improvements Network policy (egress firewalls) RBAC (define what users and service accounts can do what) Use namespaces per tenant and think hard about multi-tenancy Use the CIS guides for lockdown of K8S and the host Kube-bench Difference between containers and sandboxing   Roll your own -     Containers         Using public registries - leave you vulnerable         Use your own private repos for deploying containers   Reduce attack surface Reduce user access   Automation will allow more security to get baked in.   https://www.infoworld.com/article/3104030/security/5-keys-to-docker-container-security.html https://blog.blackducksoftware.com/8-takeaways-nist-application-container-security-guide https://www.vagrantup.com/downloads.html   https://www.vmware.com/products/thinapp.html   https://www.meetup.com/SEASec-East/events/249983387/ S3 buckets / Azure Blobs   https://docs.microsoft.com/en-us/azure/architecture/aws-professional/services   https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-policy.html   Join our #Slack Channel! Email us at bds.podcast@gmail.com or DM us on Twitter @brakesec #Spotify: https://brakesec.com/spotifyBDS #RSS: https://brakesec.com/BrakesecRSS #Youtube Channel:  http://www.youtube.com/c/BDSPodcast #iTunes Store Link: https://brakesec.com/BDSiTunes #Google Play Store: https://brakesec.com/BDS-GooglePlay Our main site:  https://brakesec.com/bdswebsite #iHeartRadio App:  https://brakesec.com/iHeartBrakesec #SoundCloud: https://brakesec.com/SoundcloudBrakesec Comments, Questions, Feedback: bds.podcast@gmail.com Support Brakeing Down Security Podcast by using our #Paypal: https://brakesec.com/PaypalBDS OR our #Patreon https://brakesec.com/BDSPatreon #Twitter: @brakesec @boettcherpwned @bryanbrake @infosystir #Player.FM : https://brakesec.com/BDS-PlayerFM #Stitcher Network: https://brakesec.com/BrakeSecStitcher #TuneIn Radio App: https://brakesec.com/TuneInBrakesec

Show: 14Show Overview: Brian and Tyler talk address some of the many layers of security required in a container environment. This show will be part of a series on container and Kubernetes security. They look at security requirement in the Container Host, Container Content, Container Registry, and Software Build Processes. Show Notes and News:10 Layers of Container SecurityGoogle, VMware and Pivotal announced a Hybrid Cloud partnership with KubernetesGoogle and Cisco announced a Hybrid Cloud partnership with Kubernetes (and more)Docker adds support for Kubernetes to DockerEERancher makes Kubernetes the primary orchestratorMicrosoft announces new Azure Container Service, AKSOracle announced Kubernetes on Oracle Linux (and some installers)Heptio announces new toolsTopic 1 - Let’s start at the bottom of the stack with the security needed on a container host.Linux namespaces - isolation Linux capabilities and SECCOMP - restrict routes, ports, limiting process calls SELinux (or AppArmor) - mandatory access controls cGroups - resource managementTopic 2 - Next in the stack, or outside the stack, is the sources of container content.Trusted sources (known registries vs. public registries (e.g. DockerHub) Scanning the content of containers Managing the versions, patches of container contentTopic 3 - Once we have the content (applications), we need a secure place to store and access it - container registries.Making a registry highly-available Who manages and audits the registry? How to scan container within a container? How to cryptographically sign images? Identifying known registries Process for managing the content in a registry (tagging, versioning/naming, etc) Automated policies (patch management, getting new content, etc.) Topic 4 - Once we have secure content (building blocks) and a secure place to store the container images, we need to think about a secure supply chain of the software - the build process.Does a platform require containers, or can it accept code? Can it manage secure builds? How to build automated triggers for builds? How to audit those triggers (webhooks, etc.)? How to validate / scan / test code at different stages of a pipeline? (static analysis, dynamic analysis, etc.) How to promote images to a platform? (automated, manual promotion, etc.)Feedback?Email: PodCTL at gmail dot comTwitter: @PodCTL Web: http://podctl.com

This week, we discuss sandboxing technologies. Most of the time, infosec people are using sandboxes and similar technology for analyzing malware and malicious software. Developers use it to create additional protections, or even to create defenses to ward off potential attack vectors. We discuss sandboxes and sandboxing technology, jails, chrooting of applications, and even tools that keep applications honest, in particular, the pledge(2) function in OpenBSD ---------- HITB announcement: “Tickets for attendance and training are on sale, And entering special code 'brakeingsecurity' at checkout gets you a 10% discount". Brakeing Down Security thanks #Sebastian Paul #Avarvarei and all the organizers of #Hack In The Box (#HITB) for this opportunity! You can follow them on Twitter @HITBSecConf. Hack In the Box will be held from 10-14 April 2017. Find out more information here: http://conference.hitb.org/hitbsecconf2017ams/ ---------        Direct Link: http://traffic.libsyn.com/brakeingsecurity/2017-004-Sandboxing_technology.mp3 iTunes: https://itunes.apple.com/us/podcast/2017-004-sandboxes-jails-chrooting/id799131292?i=1000380833781&mt=2 YouTube: https://www.youtube.com/watch?v=LqMZ9aGzYXA   Join our #Slack Channel! Sign up at https://brakesec.signup.team #RSS: http://www.brakeingsecurity.com/rss #Google Play Store: https://play.google.com/music/m/Ifp5boyverbo4yywxnbydtzljcy?t=Brakeing_Down_Security_podcast #SoundCloud: https://www.soundcloud.com/bryan-brake Comments, Questions, Feedback, or Suggestions?  Contact us via Email: bds.podcast@gmail.com #Twitter: @brakesec @boettcherpwned @bryanbrake @infosystir #Facebook: https://www.facebook.com/BrakeingDownSec/ #Tumblr: http://brakeingdownsecurity.tumblr.com/ #Player.FM : https://player.fm/series/brakeing-down-security-podcast #Stitcher Network: http://www.stitcher.com/s?fid=80546&refid=stpr #TuneIn Radio App: http://tunein.com/radio/Brakeing-Down-Security-Podcast-p801582     ----------- Show notes:   Sandboxing tech  -  https://hangouts.google.com/call/yrpzdahvjjdbfhesvjltk4ahgmf   A sandbox is implemented by executing the software in a restricted operating system environment, thus controlling the resources (for example, file descriptors, memory, file system space, etc.) that a process may use.   Various types of sandbox tech   Jails - freebsd     Much like Solaris 10’s zones, restricted operating system, also able to install OSes inside, like Debian         http://devil-detail.blogspot.com/2013/08/debian-linux-freebsd-jail-zfs.html   Pledge(8)  - new to OpenBSD     Program says what it should use, if it steps outside those lines, it’s killed     http://www.tedunangst.com/flak/post/going-full-pledge     http://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/pledge.2?query=pledge     http://www.openbsd.org/papers/hackfest2015-pledge/mgp00008.html   Chroot - openbsd, linux (chroot jails)     “A chroot on Unix operating systems is an operation that changes the apparent root directory for the current running process and its children”     Example: “www” runs in /var/www. A chrooted www website must contain all the necessary files and libraries inside of /var/www, because to the application /var/www is ‘/’   Rules based execution - AppArmor, PolicyKit, SeLinux     Allows users to set what will be ran, and which apps can inject DLLs or objects.     “It also can control file/registry security (what programs can read and write to the file system/registry). In such an environment, viruses and trojans have fewer opportunities of infecting a computer.” https://en.wikipedia.org/wiki/Seccomp https://en.wikipedia.org/wiki/Linux_Security_Modules   Android VMs   Virtual machines - sandboxes in their own right     Snapshot capability     Revert once changes have occurred     CON: some malware will detect VM environments, change ways of working   Containers (docker, kubernetes, vagrant, etc)     Quick standup of images     Blow away without loss of host functionality     Helpful to run containers as an un-privileged user. https://blog.jessfraz.com/post/getting-towards-real-sandbox-containers/   Chrome sandbox: https://chromium.googlesource.com/chromium/src/+/master/docs/linux_sandboxing.md   Emulation Vs. Virtualization   http://labs.lastline.com/different-sandboxing-techniques-to-detect-advanced-malware  --seems like a good link   VMware Thinapp (emulator): https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1030224   (continued next page) Malware lab creation (Alienvault blog): https://www.alienvault.com/blogs/security-essentials/building-a-home-lab-to-become-a-malware-hunter-a-beginners-guide   https://www.reverse.it/   News: (assuming it goes short) SHA-1 generated certs will be deprecated soon - https://threatpost.com/sha-1-end-times-have-arrived/123061/   (whitelisting files in Apache) https://isc.sans.edu/diary/Whitelisting+File+Extensions+in+Apache/21937   http://blog.erratasec.com/2017/01/the-command-line-for-cybersec.html https://github.com/robertkuhar/java_coding_guidelines https://www.us-cert.gov/sites/default/files/publications/South%20Korean%20Malware%20Attack_1.pdf#   https://www.concise-courses.com/security/conferences-of-2017/