On Thu, 2009-08-06 at 14:50 -0500, Serge E. Hallyn wrote: > Quoting Dave Airlie (airlied@xxxxxxxxxx): > > Maybe we could do something with SELinux, but I don't think > > we can do anything without getting revoke. or maybe some > > process capabilties if such things worked. > > The non-kms drivers could carry fe=on,fI=CAP_SYS_RAWIO (or whatever > they need) and userids or groups allowed to run X could get pI=CAP_SYS_RAWIO > at login through pam_cap.so. > > If you also make the x driver setuid-root, then on filesystems (like > NFS) or kernels which don't support file capabilities, it'll run setuid > root as it does now, while if file caps are supported then it should run > as the calling user with just the granted capabilities. It doesn't work like that. Drivers are DSOs, not executables. You don't get capabilities magically blessed into your executable just because you dlopen()d a DSO that has them set. Also, having actually done the audit for this, the set of capabilities the X server would need to run with restricted-caps is essentially equivalent to root in the first place. SYS_RAWIO + SYS_ADMIN + DAC_OVERRIDE plus some others I'm forgetting. Really not a solution. - ajax
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
