Hi Luke,

I should point out, the ACL criteria for matching processes do not all have
to be specified, specifically for the reason you point out. Using the
SHA256 to match the process should be a tool of last resort, useful only
when the executable's path, inode number, and PID listing commands are
unreliable (for example, a program that runs from an arbitrary location but
for which no PID listing program can be created). Also, taking the SHA256
would be very slow compared to the other criteria. I'll update the design
document to emphasize that vdev does not need all of the criteria to be
set--just the ones that describe the class of processes the ACL affects.

As much as I would like to revoke file descriptors, I'm afraid there's no
way to do this that I know of without the kernel's help (but I'd love to
learn of one). Systemd-logind has the same problem--once a process opens a
file descriptor, another process can't force it to close it (i.e. with
systemd-logind, the client can simply dup(2) the file descriptor before
systemd-logind closes it). FreeBSD has revoke(2), but AFAIK there is no
equivalent syscall for Linux.

-Jude

On Fri, Jan 2, 2015 at 10:48 AM, Luke Diamand <luke@???> wrote:

> Interesting read, thanks!
>
> The ACL logic though doesn't seem quite right.
>
> Having to do SHA digests on binaries to be sure you're granting access to
> the right program doesn't seem correct at all. It's fragile: if the program
> is updated with a new version it will stop working until the ACL is
> updated, and if it starts using a helper program that will have to be added
> to the ACL as well.
>
> I wonder if it's possible to use session-id instead?
>
> Looking quickly through the code, I couldn't see any way that it can
> *revoke* access. i.e. you've got a session for user 'A', and then switch to
> a new session for user 'B'. User 'A' should no longer have access to things
> like the microphone, or the camera. If they've already got /dev/video0
> opened, then their file descriptor needs to be closed (or rendered
> inoperative in some other way).
>
> Luke
>
>
>
>
> On 02/01/15 08:58, Jude Nelson wrote:
>
>> Hey everyone,
>>
>> I just thought I'd post an update on vdev, since I'd mentioned earlier
>> that I was shooting for packages by now. It will take a couple more
>> days, but I'm pleased to say that the pre-alpha vdev can do the following:
>>
>> * populate itself with all block and char devices known to sysfs
>> * hide or change the permissions on devices based on which process is
>> asking
>> * run shell scripts as a result of devices appearing or getting removed
>> * create device nodes with user-defined paths
>>
>> I've added automatic build and packaging scripts to vdev and its
>> dependencies (fskit and libpstat) if you're brave enough to play around
>> with it :) Don't try using it for early boot, though--that's not yet
>> tested.
>>
>> I've also written a design document here, with a development roadmap:
>> http://judecnelson.blogspot.com/2015/01/introducing-vdev.html
>>
>> Happy Gregorian New Year!
>> -Jude
>>
>>
>> _______________________________________________
>> Dng mailing list
>> Dng@???
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>
>>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>