U.V. Ravindra wrote:
> Garrett D'Amore wrote at Tue Jul 21 2009 17:30:57 GMT-0700 (PDT):
>> Ah, there was materials posted in the case directory. You didn't
>> indicate that. I suppose I should have checked there first.
>>
>> There are still some security concerns though, as fakeroot seems to use
>> TCP sockets for communication with faked. I'd like this to be more
>> explicitly spelled out.
>
> The version of fakeroot targeted by this case does not communicate
> over TCP. fakeroot can be built to use TCP sockets or System V IPC.
> System V IPC is the default, and that's the one we are seeking to
> integrate.
>
>> One can imagine subverting this channel to alter
>> the package contents (I'm not sure how you'd use this -- to change
>> ownership of a file... could it do more worse things than that?)
>
> A fakeroot'ed process runs under the userid which initiates
> the fakeroot session. It cannot really do anything the user
> couldn't do some other way. In other words, no specific
> security violations are made possible by fakeroot.
>
> For example, consider a user who doesn't have permissions to
> create a block device using mknod. This user can run mknod
> under fakeroot, and the operation will "succeed." But, no
> sooner than the fakeroot session ends, than the actual reality
> becomes evident -- what was created is just a regular (empty)
> file; it's just being 'fakely' reported to the user as a
> block special file.
My point is that if there was a TCP session that was subverted, you
could arrange to alter the UID that was stored in the archive by
changing the UID reported to the archiver. Its a goofy attack vector,
and irrelevant since I think System V IPC is pretty much immune to this.
>
>> What is the stability of the save files?
>
> They are not considered stable.
>
> The save files are only useful if the user wants to preserve
> the 'fake' appearances from one session to the next. To use
> the mknod example from above, if the user exited the fakeroot
> session without storing to a save file, all the fake information
> will be lost. The next time the user starts a fakeroot session,
> the 'mknod'ed file will be reported only as a regular file.
> On the other hand if the session were to be saved and reloaded
> in the new session, it will be reported as a block special file.
>
> The files can be removed or edited outside of the fakeroot
> session. If this is done, some or all information in them
> can be lost.
Understood. And I'm happy with that. Lets put the save files as a
Volatile interface, or even Not-An-Interface, then. Agree?
>
>> The --cleanup makes references to semaphores, but I don't see
>> information about how those are used/created? How is faked started?
>> Automatically by fakeroot, or via some other scheme?
>
> It's started automatically by fakeroot. It can be invoked by
> the user directly, but that won't be of any use unless there's
> a fakeroot at the other end.
Okay. Probably the man page should have stated that... if it did I
missed it. But then I missed so much other material in the case review
up front, I am hesitant to make any other claims about the case
materials and put yet more egg on my face. :-)
- Garrett
