On Sat, Nov 21, 2015 at 06:39:03PM +0100, Alexandre Detiste wrote: > Le samedi 21 novembre 2015, 10:27:29 David Kalnischkies a écrit : > > On Fri, Nov 20, 2015 at 01:42:34PM +0100, Alexandre Detiste wrote: > > That is most likely of no real concern to the user hence its only > > a notice, but in theory at least the attack surface is bigger (local > > disk you say, but what seems to be local for apt could very well be e.g. > > in an NFS mountpoint or otherwise moved over a more or less secure > > channel) and even in your example an evil tchet (you are root at the > > moment, so who knows how nice that tchet guy is) could do bad things… > > > > So, as we automatically disable a security feature here we have to print > > "something" to indicate this – but if you have a suggestion on how to > > improve this "something" I am all ears. :) > > So, a world-readable location under /home wouldn't trigger this warning, > but a not world-readable will. Any untrusted user can do chmod a+r on it's files, > that doesn't make those any more secure/trustworthty. It isn't any trustworthier, but it is a tiny bit more secure as the process who gets the file will do so without root rights. Constructing an attack here is a bit esoteric/strange as we aren't really concerned about an evil tchet in this scenario – I was just trying to give another example which isn't blantly obvious for many people, but that might have made it worse –, but about another user who manages to take over the process responsible for getting the file. In a http context that is easy to imagine, its a bit harder to imagine with file. The problem with home is btw not the not-readable part – the default umask allows reading by everyone. The problem is with the home-directory itself which isn't a+x (by default for good reasons). > Maybe a warning for any file writable by anyone =! root would make more sense. That might be an interesting thing to do and help in the evil tchet scenario – unfortuently its also very hard to do. In practice, it would mean the directories leading up to the file would need to be owned by root as any other owner could change the path inbetween. That happens not too often as you usually don't want to create a repository as root. Its a lot more likely that you create the repository with a 'trusted' unprivileged user. Having the repository world readable on the other hand isn't hard as it just means that every directory below the repository needs to be 'executable' for everyone – and the content of a repository is no secret as apt is going to publish it in a wellknown spot for everyone to read¹. ¹ and that is one of the problems in the takeover scenario: If I can convience (e.g. via symlinks) apt to read and copy a previously root-only file like /etc/shadow to this wellknown location I can read it as well. If file would be run as _apt my little scheme fails. (Now replace this "with symlinks" into me fiddling with the data-streams between NFS client and server to have a similar effect). > Administrators doing "apt-get install /home/<...>.deb" should know what they are doing. Indeed, but with that argument downgrades or unauthenticated packages wouldn't need an extra warning either as it should be clear, but we still do it. The message is a bit strange and might be confusing (if you have a better alternative feel free to suggest one!), but we can't just disable a security feature without saying anything. Its already borderline that we disable it automatically… "You aren't driving on an official road let me disable the airbag system for you". As the driver, that might confuse you, but its probably better this way than telling your next of kin that you hadn't read the fine print careful enough: "We are sorry for your lose, but relying on the airbag in such a situation was a lethal mistake". > Fun fact: tchet is derived from "cat (the animal)", and I do have a cat > that is not evil but has that "tortitude" thing. Fun fact: Everytime I read "cat (the animal)" I wonder what people who think "cat (the program)" imagine what "the internet is for cat pictures" means. ;) Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature