Re: RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
On Tue, Dec 21, 2010 at 10:37:44PM +0100, Miloslav Trmač wrote devel: Colin Walters píše v Út 21. 12. 2010 v 11:47 -0500: But they still have uid 0, which typical system installation allows root to do things. For example, /bin/sh is 0755 and /bin is also 0755 perms. A disarmed root process can still trojan a system. But what if we got rid of all the read/write permissions for root? So...right, we can do these small changes, and then if we do this BIG CHANGE, it all works!. But this feature doesn't include BIG CHANGE, and there are no plans to, right? No. The original plans didn't count with the fact that changing permissions by owner does not require any capabilities either. If an attacker were controlling a process running with uid 0 and no capabilities at all, and /bin/sh were 0555, nothing prevents the attacker from chmod()ing /bin/sh to 0755 and overwriting it. This makes any attempts to change the file permissions rather pointless. Ok, so who says that the files must be owned by root? Make them owned by some other user -- say, bin? (or does that have another use that my google search isn't coming up with?) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Integrity protection of fetches
On Fri, Aug 06, 2010 at 04:34:19AM -0500, Mike McGrath wrote: On Fri, 6 Aug 2010, Mike McGrath wrote: On Fri, 6 Aug 2010, Till Maas wrote: On Thu, Aug 05, 2010 at 04:32:36PM -0500, Mike McGrath wrote: We also use SSHFP records for those of you that want to enable VerifyHostKeyDNS yes in their ~/.ssh/config files. Not all of our hosts have it but many of our 'user' based external hosts do (pkgs, fedorapeople, fedorahosted, etc) Afaik the SSHFP records are not protected against tampering by an MITM attacker. snip Side note on this: Combined with DNSSEC, this actually would protect against a MITM attacker. Not only that, but they *are* signed, and the signing key is in the ISC DLV registry. You just need a name server that has DNSSEC enabled and uses the ISC DLV registry (output trimmed for relevance): $ dig +adflag -t sshfp pkgs.fedoraproject.org ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3 ;; QUESTION SECTION: ;pkgs.fedoraproject.org.IN SSHFP ;; ANSWER SECTION: pkgs.fedoraproject.org. 3600IN SSHFP 1 1 2AB094461D34656B4704B4EDBCF002A09EBCE4F7 Note the ad flag, which indicates that the answer is authentic. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Integrity protection of fetches
On Fri, Aug 06, 2010 at 12:54:23PM +0200, Till Maas wrote: On Fri, Aug 06, 2010 at 04:31:00AM -0500, Mike McGrath wrote: On Fri, 6 Aug 2010, Till Maas wrote: On Thu, Aug 05, 2010 at 04:32:36PM -0500, Mike McGrath wrote: We also use SSHFP records for those of you that want to enable VerifyHostKeyDNS yes in their ~/.ssh/config files. Not all of our hosts have it but many of our 'user' based external hosts do (pkgs, fedorapeople, fedorahosted, etc) Afaik the SSHFP records are not protected against tampering by an MITM attacker. They're better then ssh alone. They're only used for the first initation. So you'd have to be MITM'ed on the first connection in which case you're right, they wouldn't protect against that. Afaik using the SSHFP records make SSH not warn the user that the host key is not verified. If SSH would e.g. warn that the host key is unknown, but at least matches the SSHFP record, then it might be a little better. But actually it makes MITM attacks easier, because if one tampers the DNS response and the SSH connection, then the user does not even get a warning on the first attempt, making the situation even worse IMHO. And SSH is only vulnerable to MITM attacks on the first connection in general and I guess that SSHFP records are not used anymore after the first connection. What would they be good for when the host key is already known to SSH? openssh is more paranoid than that. An unsigned, unvalidated SSHFP record will be treated just like the server response is today -- the user will be shown the fingerprint and asked if it's correct. Only if the response is marked with the AD flag (indicating that the resolver has checked the signature and it's ok) does openssh trust it automatically. I know this because I've tried all three: unsigned, signed but no AD flag on the response, signed with AD flag. If you really want to argue about security, I'll point out that this isn't completely bulletproof the way Fedora works today. The host (your computer) runs a stub resolver that communicates with the recursive DNS server (typically another computer) over an unauthenticated connection. The stub resolver trusts the recursive resolver to only set the AD flag in its response when the answer is trusted, and to not set it when it's not. If you're talking directly to the authoritative nameserver, it's not allowed to validate its own response, so it'll never set the AD flag. Ideally (from this perspective), the host would validate the response itself. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linker weirdness: could not read symbols: Invalid operation
On Mon, Mar 15, 2010 at 05:27:55PM -0700, Adam Williamson wrote: On Mon, 2010-03-15 at 15:48 -0700, John Reiser wrote: could not read symbols: Invalid operation Could Invalid operation be an error message that corresponds to an error from a system call? Apply 'strace' to the link step to see what happens shortly before the write() to stderr. Huh. That's odd. When I run the exact command that was run during the compile (copy/paste), it succeeds. Makes doing the above a bit hard :) Gonna run the build through mock and see what happens... That sounds like a SELinux policy issue. Are you getting any AVCs? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
