Re: Introducing rlintian ("restricted lintian")
* 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.
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.
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.
sub untaint_arg {
my ($arg) = @_;
if ($arg =~ m{^ ( [^ & ; | \$ \( \) ]*+ ) $}xsm) {
return $1;
}
Some special characters are missing:
` ' " ? * ! { }
Whitespace probably shouldn't be allowed either.
if (! -f $filename) {
print STDERR "$filename is not a file!\n";
You should probably also ensure that the file is not 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 ^/$.
--
Jakub Wilk
Reply to: