Conversation
…-kernel-editv1) with no host scoping | admin auth with enabled clipboard in images/chromium-headful
There was a problem hiding this comment.
What Changed
This PR successfully enables clipboard functionality for all users by addressing a limitation in the upstream neko image. The key changes include:
- Updating the
Dockerfileto use a custom-builtneko/chromiumimage (ghcr.io/raiden-staging/neko/chromium:3.0.6-kernel-editv1) where host-only clipboard controls are disabled. - Reconfiguring
neko.yamlto switch fromnoauthto amultiuserauthentication provider, adding distinctadminanduserprofiles with specific permissions. - Updating the client-side auto-login credentials in
connect.vueto use the newadminprofile.
Risks / Concerns
This PR introduces a few security concerns that should be addressed:
- Supply Chain: The new base image
ghcr.io/raiden-staging/neko/chromium:3.0.6-kernel-editv1in theDockerfileis not pinned with a digest hash. This can lead to non-reproducible builds and supply chain vulnerabilities. - Weak Credentials: A hardcoded password "admin" is used in
neko.yaml. This should be replaced with a stronger, configurable secret. - Excessive Permissions: In
neko.yaml, regular users are grantedcan_host: truepermissions, which may be unnecessary and could allow them to take control of sessions from admins.
3 files reviewed | 3 comments | Review on Mesa | Edit Reviewer Settings
|
|
||
| FROM ghcr.io/m1k1o/neko/chromium:3.0.6 AS neko | ||
| #FROM ghcr.io/m1k1o/neko/chromium:3.0.6 AS neko | ||
| FROM ghcr.io/raiden-staging/neko/chromium:3.0.6-kernel-editv1 AS neko |
There was a problem hiding this comment.
Consider adding a version pin or digest hash to ensure reproducible builds and avoid potential supply chain risks. For example: FROM ghcr.io/raiden-staging/neko/chromium:3.0.6-kernel-editv1@sha256:... or at minimum document the source commit/tag this image was built from for audit purposes.
Type: Security | Severity: Medium
| provider: "noauth" | ||
| provider: multiuser | ||
| multiuser: | ||
| admin_password: "admin" |
There was a problem hiding this comment.
Using "admin" as the admin password is a security risk, even in development environments. Consider using a stronger password or making this configurable via environment variables.
Type: Security | Severity: Medium
| can_login: true | ||
| can_connect: true | ||
| can_watch: true | ||
| can_host: true |
There was a problem hiding this comment.
Both admin and user profiles have can_host: true. While this may be intentional for clipboard functionality, consider if regular users really need host permissions, as this could allow them to take control of the session from admins.
Type: Security | Severity: Medium
There was a problem hiding this comment.
What Changed
This PR fixes clipboard functionality in the chromium-headful image. The core change involves switching to a custom-built base image, ghcr.io/raiden-staging/neko/chromium:3.0.6-kernel-editv1, which removes the upstream restriction that limited clipboard access to host users only. To support this, neko.yaml was updated to use a multiuser authentication provider, defining an admin profile with clipboard permissions enabled. Consequently, the frontend component connect.vue was updated to auto-login with the new admin credentials.
Risks / Concerns
Excellent work resolving the clipboard issue by creating a custom neko image. The primary concern is the significant build time (40+ mins) for this custom image, which could slow down future iterations. Also, note that the auto-login credentials are now part of the client-side code in connect.vue.
3 files reviewed | 0 comments | Review on Mesa | Edit Reviewer Settings
| can_access_clipboard: true | ||
| sends_inactive_cursor: true | ||
| can_see_inactive_cursors: true | ||
| user_password: "neko" |
There was a problem hiding this comment.
Bug: Default Passwords Expose Admin Access
Weak default passwords are hardcoded for admin ("admin") and user ("neko") accounts in the neko.yaml configuration under the multiuser provider. This creates a security vulnerability, allowing unauthorized administrative access, including full clipboard and hosting privileges, if not changed upon deployment.
Locations (1)
| FROM ghcr.io/m1k1o/neko/chromium:3.0.6 AS neko | ||
| #FROM ghcr.io/m1k1o/neko/chromium:3.0.6 AS neko | ||
| FROM ghcr.io/raiden-staging/neko/chromium:3.0.6-kernel-editv1 AS neko | ||
| # ^--------- edited + rebuilt neko:chromium to disable host only on clipboard events |
There was a problem hiding this comment.
Hey @raiden-staging I've forked neko over here: https://github.com/onkernel/neko
Could you open a PR on that repo with this change?
|
included with #46 ✅ |
(Issue #31 , cont. from PR #36 )
Fix :
m1k1o/neko/chromium:3.0.6only enables clipboard controls for hostsneko:base&neko:chromiumbuildsraiden-staging/nekoDockerfileFROM ghcr.io/raiden-staging/neko/chromium:3.0.6-kernel-editv1 AS nekoClipboard now works 👍
Notes
neko:chromiumif we are to expose the neko websockets and events directly as part of the computer controls apis tooTL;DR
Fixed clipboard functionality in the
chromium-headfulimage by using a customnekobase image that disables host-only clipboard restrictions and configuring an admin user.Why we made these changes
The previous
nekoimage (m1k1o/neko/chromium:3.0.6) only enabled clipboard controls for hosts, which was insufficient for the intended operation. This change addresses that limitation by integrating a customnekobuild where host-only controls are disabled, ensuring clipboard access for all users, specifically the 'admin' profile.What changed?
ghcr.io/raiden-staging/neko/chromium:3.0.6-kernel-editv1as the base image, a custom build that disables host-only clipboard events.noauthtomultiuser, adding detailed password settings and permission profiles for admin and regular users.Validation