Darren J Moffat wrote:
> Enrico Perla wrote:
>>
>> Darren J Moffat wrote:
>>> What is the method credential section of the SMF manifest used to
>>> start the vbios service ? ie what user/group id does it run as and
>>> what privileges(5) does it require.
>> It runs as root and needs to open /dev/xsvc to map the BIOS image. After
>> that, it needs to be able to do in/out assembly instruction (so,
>> basically, it needs to be able to set its IOPL to 3).
>> I haven't set so far any specific privilege on the daemon since either
>> /dev/xsvc or in/out look to me as a pretty good way to take over the
>> system, if vbiosd proves to be vulnerable.
>>
>> Actually, though, we are a bit re-designing vbiosd (there was another
>> service that was only responsible of checking if gdm started and
>> receiving SIGTHAW to catch resumes that we are merging into vbiosd in
>> order to have a single service). Since that will likely lead to two
>> different threads, maybe we want to separate the privileges there? What
>> would be your suggestion?
>
> I'd say in that case you aren't ready for ARC review if you don't know
> what vbiosd does.
I do know what it does. And the code is getting 'merged' with another
code which is already available. I can point you to a webrev, if you
need to.
>
> It isn't possible for the different threads to run with separate
> privileges
Yes, what I meant was to use fork() over creating threads. But since the
code that would be separated is small and has no interaction with the
user, living with full privileges for that part too is an acceptable option.
> It sounds like because of its use of /dev/xsvc to map the BIOS
> image there is no option but to run as root with all privilege. Which
> is very unfortunate but I don't expect this project to provide a means
> other than /dev/xsvc to do that.
>
Which was my original guess. And the in and outs operation are important
as well, actually more determinant: while /dev/xsvc is meant to be used
only at startup, ins and outs are done all the time. Also, vbiosd
emulates 16-bit code: if someone is able to change the code that gets
emulated it can do again pretty much whatever it wants.
vbiosd door is protected by accepting only kernel commands.
- Enrico
