{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiandmzjjx2b7lxhpm7663dsio6dljtnqrxqkeul6vkqycp2j5zdxa",
    "uri": "at://did:plc:46ti67tc37qcmwp2vaynk6fq/app.bsky.feed.post/3mluyuqhcupm2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreifqaymphlhaou7ymuxlsdcq46k6c4k27dbs2lrqq2rxp5ioaxmdoy"
    },
    "mimeType": "image/jpeg",
    "size": 8554
  },
  "path": "/2026/05/15/debian-selinux-ssh-keysign-pwn/",
  "publishedAt": "2026-05-15T09:19:23.440Z",
  "site": "https://etbe.coker.com.au",
  "tags": [
    "the ssh-keysign-pwn exploit [1]",
    "https://github.com/0xdeadbeefnetwork/ssh-keysign-pwn",
    "Copy Fail on Debian and SE Linux",
    "Dirty Frag on Debian and SE Linux",
    "Google Chrome and SE Linux"
  ],
  "textContent": "I just tested out the ssh-keysign-pwn exploit [1] on Debian kernel 6.12.74+deb13+1-amd64 which was released before these exploits.\n\nWhen **sshkeysign_pwn** is run as **user_t** the following is logged in the audit log and it fails to exploit anything:\n\n\n    type=SYSCALL msg=audit(1778831599.951:22353257): arch=c000003e syscall=438 success=no exit=-1 a0=3 a1=c a2=0 a3=1b8020 items=0 ppid=5632 pid=6654 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=144 comm=\"sshkeysign_pwn\" exe=\"/home/test/a/ssh-keysign-pwn/sshkeysign_pwn\" subj=user_u:user_r:user_t:s0 key=(null)ARCH=x86_64 SYSCALL=pidfd_getfd AUID=\"test\" UID=\"test\" GID=\"test\" EUID=\"test\" SUID=\"test\" FSUID=\"test\" EGID=\"test\" SGID=\"test\" FSGID=\"test\"\n    type=PROCTITLE msg=audit(1778831599.951:22353257): proctitle=\"./sshkeysign_pwn\"\n    type=AVC msg=audit(1778831599.951:22353258): avc:  denied  { ptrace } for  pid=6654 comm=\"sshkeysign_pwn\" scontext=user_u:user_r:user_t:s0 tcontext=user_u:user_r:user_t:s0 tclass=process permissive=0\n\nWhen it is run as **unconfined_t** the contents of the **/etc/ssh/ssh_host_ecdsa_key** file are correctly displayed on standard out in about 10ms, the file in question is only readable by root and a non-root user can use this exploit to read it.\n\nIt wouldn’t be uncommon to have a system configured to allow users to trace their own processes. The following policy addition grants access for the user to trace their own processes:\n\n\n    allow user_t self:process ptrace;\n\nWith that in place the **sshkeysign_pwn** exploit still doesn’t work and there are logs like the following:\n\n\n    type=AVC msg=audit(1778833455.726:57355191): avc:  denied  { read } for  pid=6941 comm=\"ssh-keysign\" name=\"ssh_host_rsa_key\" dev=\"vda\" ino=15492 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:sshd_key_t:s0 tclass=file permissive=0\n    type=SYSCALL msg=audit(1778833455.726:57355191): arch=c000003e syscall=257 success=no exit=-13 a0=ffffffffffffff9c a1=55eadec43061 a2=0 a3=0 items=0 ppid=6933 pid=6941 auid=1000 uid=1000 gid=1000 euid=0 suid=0 fsuid=0 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=144 comm=\"ssh-keysign\" exe=\"/usr/lib/openssh/ssh-keysign\" subj=user_u:user_r:user_t:s0 key=(null)ARCH=x86_64 SYSCALL=openat AUID=\"test\" UID=\"test\" GID=\"test\" EUID=\"root\" SUID=\"root\" FSUID=\"root\" EGID=\"test\" SGID=\"test\" FSGID=\"test\"\n\nSo if you could find some secret data in a file that’s only restricted by Unix permissions and **user_t** is granted ptrace access then a variant of that exploit could work.\n\nWhen user_t is allowed ptrace access the **chage_pwn** exploit fails with the following log entries, so any binary that runs in a different domain can’t be used in that situation.\n\n\n    type=AVC msg=audit(1778833908.020:57434896): avc:  denied  { ptrace } for  pid=7037 comm=\"chage_pwn\" scontext=user_u:user_r:user_t:s0 tcontext=user_u:user_r:passwd_t:s0 tclass=process permissive=0\n    type=SYSCALL msg=audit(1778833908.020:57434896): arch=c000003e syscall=438 success=no exit=-1 a0=3 a1=5 a2=0 a3=1b7e00000000 items=0 ppid=5632 pid=7037 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=144 comm=\"chage_pwn\" exe=\"/home/test/a/ssh-keysign-pwn/chage_pwn\" subj=user_u:user_r:user_t:s0 key=(null)ARCH=x86_64 SYSCALL=pidfd_getfd AUID=\"test\" UID=\"test\" GID=\"test\" EUID=\"test\" SUID=\"test\" FSUID=\"test\" EGID=\"test\" SGID=\"test\" FSGID=\"test\"\n\n## Conclusion\n\nIn a “strict” configuration with users having the **user_t** domain a Debian system is not vulnerable to these exploits unless there is some configuration error or some unusual configuration choices. Users with the **unconfined_t** domain can successfully run the exploits.\n\n  * [1] https://github.com/0xdeadbeefnetwork/ssh-keysign-pwn\n\n\n\nRelated posts:\n\n  1. Copy Fail on Debian and SE Linux I have just learned of the Copy Fail kernel vulnerability...\n  2. Dirty Frag on Debian and SE Linux Hot on the heels of the Copy Fail vulnerability [1]...\n  3. Google Chrome and SE Linux [107108.433300] chrome[12262]: segfault at bbadbeef ip 0000000000fbea18 sp 00007fffcf348100 error...\n\n",
  "title": "Russell Coker: Debian SE Linux and ssh-keysign-pwn",
  "updatedAt": "2026-05-15T08:48:15.000Z"
}