u/secsecseec

Herkese merhaba,

Özellikle bilgisayar mühendisliği öğrencilerinin ilgisini çekebileceğini düşündüğümüz bir süreç başlatıyoruz. Tabii ki sadece CENG öğrencilerine değil, siber güvenlik alanına gerçekten ilgi duyan herkese açık.

Milenium Akademi olarak “OwlCamp” adını verdiğimiz dikey uzmanlık odaklı bir siber güvenlik kampı hazırlıyoruz.

Bu süreçte amacımız insanları aylarca sadece temel konularda tutmak değil. Temelden başlayıp kısa sürede gerçek dünya senaryolarına, pratik çalışmalara ve teknik uzmanlaşmaya geçmek istiyoruz.

Biz burada sadece tool, payload veya hazır komut öğretmeyi hedeflemiyoruz. Asıl amacımız saldırı mantığını, problem çözme bakış açısını ve gerçek dünyada nasıl düşünülmesi gerektiğini öğretmek.

Kamp boyunca:

- haftada 4 gün eğitim,

- haftada 1 gün herkese açık ücretsiz yayın,

- red team bakış açısı,

- sosyal mühendislik,

- malware / exploit development,

- bug bounty tarafında teknik yönlendirme,

- Slack topluluğu üzerinden öğrenciler ve eğitmenlerle network

gibi başlıklar olacak.

Kısacası sadece ders izlenen bir yapı değil; insanların birlikte öğrendiği, soru sorduğu, pratik yaptığı ve sektöre daha bilinçli hazırlanabildiği bir topluluk kurmaya çalışıyoruz.

İncelemek isteyenler:

https://mileniumakademi.com

Teşekkürler.

Hello again, I’m azqzazq1, a cybersecurity researcher.

My previous research, SunnyDayBPF, was recently featured by Ollie Whitehouse, CTO at the UK NCSC, in the Cyber Defence Analysis weekly summary.

Now I’m working on a new low-level Linux security research idea and I’d really like to hear opinions from people interested in eBPF, LSMs, AppArmor, and Linux hardening.

While spending more time with BPF internals, I noticed an interesting trust-boundary problem.

At a high level, the LSM framework prevents one LSM from simply overriding another LSM’s deny decision. However, eBPF tracing mechanisms can operate outside that LSM decision flow. This creates an interesting gap when combined with pathname-based MAC enforcement.

The research explores whether pre-LSM pathname manipulation through eBPF can cause AppArmor to evaluate a different path than the one originally requested by the user process.

In other words:

Can the security decision remain technically “valid” while the observed enforcement target is shifted before the LSM check?

I’m currently calling this research:

LID — Linux Integrity Drift

The focus is not “turning off AppArmor”, but understanding how kernel tracing, pathname-based access control, and security enforcement assumptions can drift from each other under specific conditions.

I’d love to hear thoughts from people working on Linux security, eBPF, AppArmor, LSM internals, or runtime detection.

Security assumptions killing all the ecosystem.

Hello again, I’m azqzazq1, a cybersecurity researcher.

My previous research, SunnyDayBPF, was recently featured by Ollie Whitehouse, CTO at the UK NCSC, in the Cyber Defence Analysis weekly summary.

Now I’m working on a new low-level Linux security research idea and I’d really like to hear opinions from people interested in eBPF, LSMs, AppArmor, and Linux hardening.

While spending more time with BPF internals, I noticed an interesting trust-boundary problem.

At a high level, the LSM framework prevents one LSM from simply overriding another LSM’s deny decision. However, eBPF tracing mechanisms can operate outside that LSM decision flow. This creates an interesting gap when combined with pathname-based MAC enforcement.

The research explores whether pre-LSM pathname manipulation through eBPF can cause AppArmor to evaluate a different path than the one originally requested by the user process.

In other words:

Can the security decision remain technically “valid” while the observed enforcement target is shifted before the LSM check?

I’m currently calling this research:

LID — Linux Integrity Drift

The focus is not “turning off AppArmor”, but understanding how kernel tracing, pathname-based access control, and security enforcement assumptions can drift from each other under specific conditions.

I’d love to hear thoughts from people working on Linux security, eBPF, AppArmor, LSM internals, or runtime detection.

Security assumptions killing all the ecosystem.

Hello again, I’m azqzazq1, a cybersecurity researcher.

My previous research, SunnyDayBPF, was recently featured by Ollie Whitehouse, CTO at the UK NCSC, in the Cyber Defence Analysis weekly summary.

Now I’m working on a new low-level Linux security research idea and I’d really like to hear opinions from people interested in eBPF, LSMs, AppArmor, and Linux hardening.

While spending more time with BPF internals, I noticed an interesting trust-boundary problem.

At a high level, the LSM framework prevents one LSM from simply overriding another LSM’s deny decision. However, eBPF tracing mechanisms can operate outside that LSM decision flow. This creates an interesting gap when combined with pathname-based MAC enforcement.

The research explores whether pre-LSM pathname manipulation through eBPF can cause AppArmor to evaluate a different path than the one originally requested by the user process.

In other words:

Can the security decision remain technically “valid” while the observed enforcement target is shifted before the LSM check?

I’m currently calling this research:

LID — Linux Integrity Drift

The focus is not “turning off AppArmor”, but understanding how kernel tracing, pathname-based access control, and security enforcement assumptions can drift from each other under specific conditions.

I’d love to hear thoughts from people working on Linux security, eBPF, AppArmor, LSM internals, or runtime detection.

Security assumptions killing all the ecosystem.

Hello again, I’m azqzazq1, a cybersecurity researcher.

My previous research, SunnyDayBPF, was recently featured by Ollie Whitehouse, CTO at the UK NCSC, in the Cyber Defence Analysis weekly summary.

Now I’m working on a new low-level Linux security research idea and I’d really like to hear opinions from people interested in eBPF, LSMs, AppArmor, and Linux hardening.

While spending more time with BPF internals, I noticed an interesting trust-boundary problem.

At a high level, the LSM framework prevents one LSM from simply overriding another LSM’s deny decision. However, eBPF tracing mechanisms can operate outside that LSM decision flow. This creates an interesting gap when combined with pathname-based MAC enforcement.

The research explores whether pre-LSM pathname manipulation through eBPF can cause AppArmor to evaluate a different path than the one originally requested by the user process.

In other words:

Can the security decision remain technically “valid” while the observed enforcement target is shifted before the LSM check?

I’m currently calling this research:

LID — Linux Integrity Drift

The focus is not “turning off AppArmor”, but understanding how kernel tracing, pathname-based access control, and security enforcement assumptions can drift from each other under specific conditions.

I’d love to hear thoughts from people working on Linux security, eBPF, AppArmor, LSM internals, or runtime detection.

Security assumptions killing all the ecosystem.

Hello again, I’m azqzazq1, a cybersecurity researcher.

My previous research, SunnyDayBPF, was recently featured by Ollie Whitehouse, CTO at the UK NCSC, in the Cyber Defence Analysis weekly summary.

Now I’m working on a new low-level Linux security research idea and I’d really like to hear opinions from people interested in eBPF, LSMs, AppArmor, and Linux hardening.

While spending more time with BPF internals, I noticed an interesting trust-boundary problem.

At a high level, the LSM framework prevents one LSM from simply overriding another LSM’s deny decision. However, eBPF tracing mechanisms can operate outside that LSM decision flow. This creates an interesting gap when combined with pathname-based MAC enforcement.

The research explores whether pre-LSM pathname manipulation through eBPF can cause AppArmor to evaluate a different path than the one originally requested by the user process.

In other words:

Can the security decision remain technically “valid” while the observed enforcement target is shifted before the LSM check?

I’m currently calling this research:

LID — Linux Integrity Drift

The focus is not “turning off AppArmor”, but understanding how kernel tracing, pathname-based access control, and security enforcement assumptions can drift from each other under specific conditions.

I’d love to hear thoughts from people working on Linux security, eBPF, AppArmor, LSM internals, or runtime detection.

Security assumptions killing all the ecosystem.

Hello again, I’m azqzazq1, a cybersecurity researcher.

My previous research, SunnyDayBPF, was recently featured by Ollie Whitehouse, CTO at the UK NCSC, in the Cyber Defence Analysis weekly summary.

Now I’m working on a new low-level Linux security research idea and I’d really like to hear opinions from people interested in eBPF, LSMs, AppArmor, and Linux hardening.

While spending more time with BPF internals, I noticed an interesting trust-boundary problem.

At a high level, the LSM framework prevents one LSM from simply overriding another LSM’s deny decision. However, eBPF tracing mechanisms can operate outside that LSM decision flow. This creates an interesting gap when combined with pathname-based MAC enforcement.

The research explores whether pre-LSM pathname manipulation through eBPF can cause AppArmor to evaluate a different path than the one originally requested by the user process.

In other words:

Can the security decision remain technically “valid” while the observed enforcement target is shifted before the LSM check?

I’m currently calling this research:

LID — Linux Integrity Drift

The focus is not “turning off AppArmor”, but understanding how kernel tracing, pathname-based access control, and security enforcement assumptions can drift from each other under specific conditions.

I’d love to hear thoughts from people working on Linux security, eBPF, AppArmor, LSM internals, or runtime detection.

Security assumptions killing all the ecosystem.

Hello again, I’m azqzazq1, a cybersecurity researcher.

My previous research, SunnyDayBPF, was recently featured by Ollie Whitehouse, CTO at the UK NCSC, in the Cyber Defence Analysis weekly summary.

Now I’m working on a new low-level Linux security research idea and I’d really like to hear opinions from people interested in eBPF, LSMs, AppArmor, and Linux hardening.

While spending more time with BPF internals, I noticed an interesting trust-boundary problem.

At a high level, the LSM framework prevents one LSM from simply overriding another LSM’s deny decision. However, eBPF tracing mechanisms can operate outside that LSM decision flow. This creates an interesting gap when combined with pathname-based MAC enforcement.

The research explores whether pre-LSM pathname manipulation through eBPF can cause AppArmor to evaluate a different path than the one originally requested by the user process.

In other words:

Can the security decision remain technically “valid” while the observed enforcement target is shifted before the LSM check?

I’m currently calling this research:

LID — Linux Integrity Drift

The focus is not “turning off AppArmor”, but understanding how kernel tracing, pathname-based access control, and security enforcement assumptions can drift from each other under specific conditions.

I’d love to hear thoughts from people working on Linux security, eBPF, AppArmor, LSM internals, or runtime detection.

Security assumptions killing all the ecosystem.

What do you think about that researching?

I’m researching a telemetry integrity question around eBPF and Linux monitoring agents.

The idea is focused on the trust boundary between read-like syscall completion and user-space agent parsing.

A simplified version of the question:

If a user-space security/logging agent successfully reads telemetry into its buffer, can that observation path still diverge from ground truth before the agent parses and forwards the data?

I’m looking for feedback from people working with eBPF on:

• whether this framing makes sense
• possible prior art
• defensive monitoring ideas
• BPF hardening approaches
• limitations around verifier/kernel behavior
• ways defenders can validate telemetry integrity across multiple sources

I have a public research repo and DOI, but I’m avoiding dropping links here in case that triggers filters. Happy to share in comments if allowed.Question: post-syscall telemetry integrity with eBPF