Re: Introducing rlintian ("restricted lintian")

[Niels Thykier <niels@thykier.net>]

On 2013-04-21 22:29, Jakub Wilk wrote:
> * Niels Thykier <niels@thykier.net>, 2013-04-21, 14:35:
>> Particularly, in aptdaemon's case Lintian is used to enforce some
>> (local?) policy requirements for installing packages. If you can
>> choose the profile or visibility settings, you can change/bypass the
>> desired policy.
> 
> As far as I can see, aptdaemon runs lintian "as the user who initiated
> the transaction". If the concern is here that said user could cause the
> transaction to succeed despite local policy saying otherwise, then
> restrictions in Lintian won't help. The user could just ptrace the
> (r)lintian process make it do whatever he wants.
> 

Seems like prctl + PR_SET_DUMPABLE should do do the trick here (but it
will probably be too late in rlintian).  Alternative su to nobody
(presuming the package is world readable) should deny a non-privileged
user from ptracing lintian.

>> So a "secure by default" Lintian could not load the user config files
>> (without an explicit --cfg or --user-dirs). It would also require
>> taint mode to protect us from PERL5LIB/PERLLIB and PERL5OPT.
> 
> There's also LD_LIBRARY_PATH (and other LD_*), which Lintian can do
> nothing about.
> 

True.  However, I suspect people to be more aware of LD_LIBRARY_PATH and
LD_PRELOAD than of PERL5LIB and PERL5OPT.  On a related note, I have
added LD_* + ptrace to the (coming?) manpage of rlintian to raise
awareness of them.

>> I propose we include a new frontend, rlintian (or some other name).
>> Its sole purpose would be to provide people with an honest chance of
>> using Lintian "right" in these cases.
> 
> I'm not convinced that there are any real-world use cases in which it
> helps. If there are, then it should be clearly documented what they are.
> 

There is a real-world use case for it.  This may sound selfish and it
probably^W is.  If we had rlintian earlier, I could have enabled user
checks by default and XDG_DATA_{HOME,DIRS} support in 2.5.12.
  However, rlintian did not exist and I was aware of the aptdaemon
codebase "might" being affected by this change.  In the end, I had no
choice but to undo the change and now wait.  Because that was the "right
thing to do" (or maybe just the "less wrong").

Beyond that, there is something nice about telling people that they
don't have to reimplement the last X steps of running Lintian without
backdoors (fvso of X and "steps").
  Sure, there is still the LD_PRELOAD/LD_LIBRARY_PATH variables and the
ptrace caveat, but it is still better than nothing.  Especially if it
means we can go back to adding features to Lintian as we please.

>> sub untaint_arg {
>>    my ($arg) = @_;
>>    if ($arg =~ m{^ ( [^ & ; | \$ \( \) ]*+ ) $}xsm) {
>>        return $1;
>>    }
> 
> Some special characters are missing:
> ` ' " ? * ! { }
> Whitespace probably shouldn't be allowed either.
> 

Thanks, I kept {} and whitespace for now though.  The {} are used in the
"magic" {VENDOR} for --profile and whitespaces "could reasonably" occur
in path names (and that sub untaints all arguments).  I added a FIXME
for that though.

>>        if (! -f $filename) {
>>            print STDERR "$filename is not a file!\n";
> 
> You should probably also ensure that the file is not a symlink.
> 

Added, though I wonder if it actually makes sense.  It does not restrict
the path (i.e. you could do some/file.changes and have some be a symlink).

>>        } elsif ($filename !~ m{ \. (?: u?deb|dsc|changes ) $}xsm) {
>>            print STDERR "$filename has unknown extension type\n";
> 
> Either drop the "m" flag or use \A/\Z instead of ^/$.
> 

Thanks, used \A and \Z.

~Niels