Technical talks at universities by agamez

Description

This project aims to empower the next generation of tech professionals by offering hands-on workshops on containerization and Kubernetes, with a strong focus on open-source technologies. By providing practical experience with these cutting-edge tools and fostering a deep understanding of open-source principles, we aim to bridge the gap between academia and industry.

For now, the scope is limited to Spanish universities, since we already have the contacts and have started some conversations.

Goals

• Technical Skill Development: equip students with the fundamental knowledge and skills to build, deploy, and manage containerized applications using open-source tools like Kubernetes.
• Open-Source Mindset: foster a passion for open-source software, encouraging students to contribute to open-source projects and collaborate with the global developer community.
• Career Readiness: prepare students for industry-relevant roles by exposing them to real-world use cases, best practices, and open-source in companies.

Resources

• Instructors: experienced open-source professionals with deep knowledge of containerization and Kubernetes.
• SUSE Expertise: leverage SUSE's expertise in open-source technologies to provide insights into industry trends and best practices.

---

Improve Development Environment on Uyuni by mbussolotto

Description

Currently create a dev environment on Uyuni might be complicated. The steps are:

• add the correct repo
• download packages
• configure your IDE (checkstyle, format rules, sonarlint....)
• setup debug environment
• ...

The current doc can be improved: some information are hard to be find out, some others are completely missing.

Dev Container might solve this situation.

Goals

Uyuni development in no time:

• using VSCode:
  • setting.json should contains all settings (for all languages in Uyuni, with all checkstyle rules etc...)
  • dev container should contains all dependencies
  • setup debug environment
• implement a GitHub Workspace solution
• re-write documentation

Lots of pieces are already implemented: we need to connect them in a consistent solution.

Resources

• https://github.com/uyuni-project/uyuni/wiki

---

SUSE AI Meets the Game Board by moio

Use tabletopgames.ai’s open source TAG and PyTAG frameworks to apply Statistical Forward Planning and Deep Reinforcement Learning to two board games of our own design. On an all-green, all-open source, all-AWS stack!

---

Results: Infrastructure Achievements

We successfully built and automated a containerized stack to support our AI experiments. This included:

• a Fully-Automated, One-Command, GPU-accelerated Kubernetes setup: we created an OpenTofu based script, tofu-tag, to deploy SUSE's RKE2 Kubernetes running on CUDA-enabled nodes in AWS, powered by openSUSE with GPU drivers and gpu-operator
• Containerization of the TAG and PyTAG frameworks: TAG (Tabletop AI Games) and PyTAG were patched for seamless deployment in containerized environments. We automated the container image creation process with GitHub Actions. Our forks (PRs upstream upcoming):
  • https://github.com/moio/TabletopGames/tree/hackweek24
  • https://github.com/moio/PyTAG/tree/hackweek24

./deploy.sh and voilà - Kubernetes running PyTAG (k9s, above) with GPU acceleration (nvtop, below)

Results: Game Design Insights

Our project focused on modeling and analyzing two card games of our own design within the TAG framework:

• Game Modeling: We implemented models for Dario's "Bamboo" and Silvio's "Totoro" and "R3" games, enabling AI agents to play thousands of games ...in minutes!
• AI-driven optimization: By analyzing statistical data on moves, strategies, and outcomes, we iteratively tweaked the game mechanics and rules to achieve better balance and player engagement.
• Advanced analytics: Leveraging AI agents with Monte Carlo Tree Search (MCTS) and random action selection, we compared performance metrics to identify optimal strategies and uncover opportunities for game refinement .
  • more about Bamboo on Dario's site
  • more about R3 on Silvio's site (italian, translation coming)
  • more about Totoro on Silvio's site

A family picture of our card games in progress. From the top: Bamboo, Totoro, R3

Results: Learning, Collaboration, and Innovation

Beyond technical accomplishments, the project showcased innovative approaches to coding, learning, and teamwork:

• "Trio programming" with AI assistance: Our "trio programming" approach—two developers and GitHub Copilot—was a standout success, especially in handling slightly-repetitive but not-quite-exactly-copypaste tasks. Java as a language tends to be verbose and we found it to be fitting particularly well.
• AI tools for reporting and documentation: We extensively used AI chatbots to streamline writing and reporting. (Including writing this report! ...but this note was added manually during edit!)
• GPU compute expertise: Overcoming challenges with CUDA drivers and cloud infrastructure deepened our understanding of GPU-accelerated workloads in the open-source ecosystem.
• Game design as a learning platform: By blending AI techniques with creative game design, we learned not only about AI strategies but also about making games fun, engaging, and balanced.

Last but not least we had a lot of fun! ...and this was definitely not a chatbot generated line!

The Context: AI + Board Games

---

ADS-B receiver with MicroOS by epaolantonio

I would like to put one of my spare Raspberry Pis to good use, and what better way to see what flies above my head at any time?

There are various ready-to-use distros already set-up to provide feeder data to platforms like Flightradar24, ADS-B Exchange, FlightAware etc... The goal here would be to do it using MicroOS as a base and containerized decoding of ADS-B data (via tools like dump1090) and web frontend (tar1090).

Goals

• Create a working receiver using MicroOS as a base, and containers based on Tumbleweed
• Make it easy to install
• Optimize for maximum laziness (i.e. it should take care of itself with minimum intervention)

Resources

• 1x Small Board Computer capable of running MicroOS
• 1x RTL2832U DVB-T dongle
• 1x MicroSD card
• https://github.com/antirez/dump1090
• https://github.com/flightaware/dump1090 (dump1090 fork by FlightAware)
• https://github.com/wiedehopf/tar1090

Project status (2024-11-22)

So I'd say that I'm pretty satisfied with how it turned out. I've packaged readsb (as a replacement for dump1090), tar1090, tar1090-db and mlat-client (not used yet).

Current status:

• Able to set-up a working receiver using combustion+ignition (web app based on Fuel Ignition)
• Able to feed to various feeds using the Beast protocol (Airplanes.live, ADSB.fi, ADSB.lol, ADSBExchange.com, Flyitalyadsb.com, Planespotters.net)
• Able to feed to Flightradar24 (initial-setup available but NOT tested! I've only tested using a key I already had)
• Local web interface (tar1090) to easily visualize the results
• Cockpit pre-configured to ease maintenance

What's missing:

• MLAT (Multilateration) support. I've packaged mlat-client already, but I have to wire it up
• FlightAware support

Give it a go at https://g7.github.io/adsbreceiver/ !

Project links

• https://g7.github.io/adsbreceiver/
• https://github.com/g7/adsbreceiver
• https://build.opensuse.org/project/show/home:epaolantonio:adsbreceiver

---

Port the classic browser game HackTheNet to PHP 8 by dgedon

Description

The classic browser game HackTheNet from 2004 still runs on PHP 4/5 and MySQL 5 and needs a port to PHP 8 and e.g. MariaDB.

Goals

• Port the game to PHP 8 and MariaDB 11
• Create a container where the game server can simply be started/stopped

Resources

• https://github.com/nodeg/hackthenet

---

CVE portal for SUSE Rancher products by gmacedo

Description

Currently it's a bit difficult for users to quickly see the list of CVEs affecting images in Rancher, RKE2, Harvester and Longhorn releases. Users need to individually look for each CVE in the SUSE CVE database page - https://www.suse.com/security/cve/ . This is not optimal, because those CVE pages are a bit hard to read and contain data for all SLE and BCI products too, making it difficult to easily see only the CVEs affecting the latest release of Rancher, for example. We understand that certain costumers are only looking for CVE data for Rancher and not SLE or BCI.

Goals

The objective is to create a simple to read and navigate page that contains only CVE data related to Rancher, RKE2, Harvester and Longhorn, where it's easy to search by a CVE ID, an image name or a release version. The page should also provide the raw data as an exportable CSV file.

It must be an MVP with the minimal amount of effort/time invested, but still providing great value to our users and saving the wasted time that the Rancher Security team needs to spend by manually sharing such data. It might not be long lived, as it can be replaced in 2-3 years with a better SUSE wide solution.

Resources

• The page must be simple and easy to read.
• The UI/UX must be as straightforward as possible with minimal visual noise.
• The content must be created automatically from the raw data that we already have internally.
• It must be updated automatically on a daily basis and on ad-hoc runs (when needed).
• The CVE status must be aligned with VEX.
• The raw data must be exportable as CSV file.
• Ideally it will be written in Go or pure Shell script with basic HTML and no external dependencies in CSS or JS.

---

OIDC Loginproxy by toe

Description

Reverse proxies can be a useful option to separate authentication logic from application logic. SUSE and openSUSE use "loginproxies" as an authentication layer in front of several services.

Currently, loginproxies exist which support LDAP authentication or SAML authentication.

Goals

The goal of this Hack Week project is, to create another loginproxy which supports OpenID Connect authentication which can then act as a drop-in replacement for the existing LDAP or SAML loginproxies.

Testing is intended to focus on the integration with OIDC IDPs from Okta, KanIDM and Authentik.

Resources

• #122254: Migrate away from login proxies to SSO

---

VulnHeap by r1chard-lyu

Description

The VulnHeap project is dedicated to the in-depth analysis and exploitation of vulnerabilities within heap memory management. It focuses on understanding the intricate workflow of heap allocation, chunk structures, and bin management, which are essential to identifying and mitigating security risks.

Goals

• Familiarize with heap
  • Heap workflow
  • Chunk and bin structure
  • Vulnerabilities
• Vulnerability
  • Use after free (UAF)
  • Heap overflow
  • Double free
• Use Docker to create a vulnerable environment and apply techniques to exploit it

Resources

• https://heap-exploitation.dhavalkapil.com/divingintoglibc_heap
• https://raw.githubusercontent.com/cloudburst/libheap/master/heap.png
• https://github.com/shellphish/how2heap?tab=readme-ov-file

---

Bot to identify reserved data leak in local files or when publishing on remote repository by mdati

Description

Scope here is to prevent reserved data or generally "unwanted", to be pushed and saved on a public repository, i.e. on Github, causing disclosure or leaking of reserved informations.

The above definition of reserved or "unwanted" may vary, depending on the context: sometime secret keys or password are stored in data or configuration files or hardcoded in source code and depending on the scope of the archive or the level of security, it can be either wanted, permitted or not at all.

As main target here, secrets will be registration keys or passwords, to be detected and managed locally or in a C.I. pipeline.

Goals

• Detection:

  • Local detection: detect secret words present in local files;
  • Remote detection: detect secrets in files, in pipelines, going to be transferred on a remote repository, i.e. via git push;

• Reporting:

  • report the result of detection on stderr and/or log files, noticed excluding the secret values.

• Acton:

  • Manage the detection, by either deleting or masking the impacted code or deleting/moving the file itself or simply notify it.

Resources

• Project repository, published on Github (link): m-dati/hkwk24;
• Reference folder: hkwk24/chksecret;
• First pull request (link): PR#1;
• Second PR, for improvements: PR#2;
• README.md and TESTS.md documentation files available in the repo root;
• Test subproject repository, for testing CI on push [TBD].

Notes

We use here some examples of secret words, that still can be improved.
The various patterns to match desired reserved words are written in a separated module, to be on demand updated or customized.

[Legend: TBD = to be done]

---

Contributing to Linux Kernel security by pperego

Description

A couple of weeks ago, I found this blog post by Gustavo Silva, a Linux Kernel contributor.

I always strived to start again into hacking the Linux Kernel, so I asked Coverity scan dashboard access and I want to contribute to Linux Kernel by fixing some minor issues.

I want also to create a Linux Kernel fuzzing lab using qemu and syzkaller

Goals

1. Fix at least 2 security bugs
2. Create the fuzzing lab and having it running

The story so far

• Day 1: setting up a virtual machine for kernel development using Tumbleweed. Reading a lot of documentation, taking confidence with Coverity dashboard and with procedures to submit a kernel patch
• Day 2: I read really a lot of documentation and I triaged some findings on Coverity SAST dashboard. I have to confirm that SAST tool are great false positives generator, even for low hanging fruits.
• Day 3: Working on trivial changes after I read this blog post: https://www.toblux.com/posts/2024/02/linux-kernel-patches.html. I have to take confidence with the patch preparation and submit process yet.
  • First trivial patch sent: using strtruefalse() macro instead of hard-coded strings in a staging driver for a lcd display
  • Fix for a dereference before null check issue discovered by Coverity (CID 1601566) https://scan7.scan.coverity.com/#/project-view/52110/11354?selectedIssue=1601566
• Day 4: Triaging more issues found by Coverity.
  • The patch for CID 1601566 was refused. The check against the NULL pointer was pointless so I prepared a version 2 of the patch removing the check.
  • Fixed another dereference before NULL check in iwlmvmparsewowlaninfo_notif() routine (CID 1601547). This one was already submitted by another kernel hacker :(
• Day 5: Wrapping up. I had to do some minor rework on patch for CID 1601566. I found a stalker bothering me in private emails and people I interacted with me, advised he is a well known bothering person. Markus Elfring for the record.

• Wrapping up: being back doing kernel hacking is amazing and I don't want to stop it. My battery pack is completely drained but changing the scope gave me a great twist and I really want to feel this energy not doing a single task for months.

  I failed in setting up a fuzzing lab but I was too optimistic for the patch submission process.

The patches

1

---