Re: F21 System Wide Change: Workstation: Disable firewall
users running applications which opening a high port in the background like license checks and so on (as example ZendStudio) will be really thankful that as default these ports are open on the WAN Why does it listen on a port for license checks? It should just contact the server and not the other way. Besides no one is stopping you from enabling the firewall. I'm going to jump into this thread here (I'm not purposely picking on this singular point). So when we have to think about security, the mindset needs to be secure by default. We shouldn't tell people they *can* enable the firewall, we tell them the can disable it. While I will agree that in a perfect world we shouldn't need a firewall, we don't live in a perfect world. Applications have bugs, they have default logins, they listen on ports they shouldn't, users have bad passwords, they have public shared folders, the list can go on for a very very long time. A firewall is an easy win here. Fedora needs to keep in mind is the safety of our users. We've lived up to this point with a firewall enabled. The solution is to fix the firewall, not disable it. If we just disable the firewall, what is our incentive to fix it? Please don't disable the firewall, it's almost certainly not the right decision, and I'm pretty sure we'll end up wishing we'd not disabled it sooner or later. Thanks. -- Josh Bressers / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
- Original Message - On Wed, Dec 04, 2013 at 05:11:16PM -0600, Ian Pilcher wrote: On 12/04/2013 04:56 PM, Brendan Jones wrote: Patching is not a problem. Unnecessary is the question. Explain to me (not you in particular Rahul) how these printf's can possibly be exploited? char *output; output = get_user_input(...); printf(output); What happens when the user enters %n? With -D_FORTIFY_SOURCE=2 the program is aborted, unless the string resides in read-only memory ;) While this response is likely meant to be a bit snarky, I'd like to explain this a bit more. The idea here is we have multiple layers of defense. We don't have to only worry about one technology. They fail from time to time, so you make sure you have a backup, and a backup of the backup, and so on. We never want to rely on one security technology to solve our problems, so we combine several. It also helps us future proof the code. Things can change in the future, by making wise decisions today we can avoid some pain tomorrow. There is also a bigger idea of making sure developers think about what they're doing. If you just smash out a printf(foo), you don't have to give the type of foo a second thought. The thinking is that if you add an extra step, it will hopefully remind the developer to think about what they're doing for a second (and hopefully prevent a bug). This is of course subjective, I can't prove it's the case. And lastly, while you can't execute arbitrary code with a %n these days (in theory), you can cause a denial-of-service, which often isn't ideal either. Thanks. -- Josh Bressers / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Enabling -Werror=format-security by default
And the very first package I maintain that appears on that list, abe, is an interesting one. The game has an internal function, path_sprintf(), which is static in Game.c. All callers of that function are visible in the same file, and all pass constant strings into the function, which passes those constant strings to sprintf(). The function's purpose is to produce a pathname for a file of interest to the caller in the game's installed location. It's too bad that gcc's analysis cannot span function calls inside a compilation unit. There really is nothing wrong with this code. You're right, some of the bugs aren't really bugs. It would be handy if there was some form of taint checking in gcc, but we have to work with what we have. We mention this in the FAQ. https://fedoraproject.org/wiki/Format-Security-FAQ#I_don.27t_process_untrusted_string.2C_this_isn.27t_an_error.21 I would rather see us future proof all code than try to figure out each possible use case. This is a bit of a blanket strategy, but I do think it will have a net benefit. It's not every day you can remove an entire class of security issues (I can count the number of times we've done this on one hand). Thanks. -- Josh Bressers / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GPG verification in SPECs
- Original Message - Hi, upstream of pam_mount pointed me to OpenSUSE's gpg-offline RPM macros at https://build.opensuse.org/package/show/Base:System/gpg-offline They allow to use a keyring and detached signature as additional source in SPECs to get both verified. Since gpg-offline's upstream is willing to create a proper release to allow easy packaging for Fedora, I wonder if I will find any obstacles when I package it. The packaging guidelines allow packaging RPM macros, therefore this should be fine. Also I am interested whether there are better options available. Hi Till, Any news on packaging this? I'm interested to see what we can do with it. Thanks. -- Josh Bressers / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: icedtea-web installed and enabled by default in Fedora 19
Is java environment the only security flawed software distributed in Fedora by default? I don't think so. Please, correct me if I'm wrong. Does it mean Fedora should drop about 1/3 of packages because they have security bugs? What about Linux Kernel? It's also buggy. Should it be not included in Fedora? This is probably the wrong way to think of it. We're not telling anyone they shouldn't be using the web plugin, we're saying it carries with it a certain amount of risk. Should we subject all users, even the ones who don't use this plugin, to that risk? We've made similar decisions in the past. Why do we turn on the firewall, or make Sendmail only listen on localhost? Sometimes it makes sense to make a decision that lowers potential risk for most users while being a slight inconvenience for other users. I think this plugin falls into that category. Thanks. -- Josh Bressers / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: icedtea-web installed and enabled by default in Fedora 19
- Original Message - Florian Weimer (fwei...@redhat.com) said: I noticed that icedtea-web (the Java browser plugin implementation for OpenJDK) is installed and enabled by default (as part of the GNOME Desktop set). This is a bit surprising, considering that the rest of the world tries to move away from Java browser plugin technology (and even browser plugin technology in general). We cannot really remove installed packages after the release, so I'm wondering if we still can fix this prior to release. We could, I suppose. What do people think? (It's just one line in comps.) Nearly all live images drop it for space reasons. I think given all the trouble this plugin has caused recently, it wouldn't be wise to install it for everyone. If you need it, great, install it, but if a users doesn't need it, it's really just creating a level of risk we probably don't want. Fedora currently has a reputation for being pretty secure, I think this could damage that reputation. Thanks. -- Josh Bressers / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
Will and Mairin had some good links talking about the merits of doing this and how hiding passwords doesn't even do all that much to help (a determined person can always just watch your keyboard). This argument isn't very solid. I mean someone can just break your window to get in your house, so locking the door is waste of time, right? The bigger issue here is we should always have the mantra secure by default. This is not secure by default. Why not use a checkbox? Well, why use a widget if we don't have to? Using a checkbox means now we have to work in another widget to the design, introducing potential padding and layout problems. It's another string that needs to be translated. It's another thing that needs a mnemonic widget. By doing the focus trick, we completely get rid of the keyboard layout problem because you can see what you're typing as you're typing it. It may also even allow us to get rid of the confirmation entries for the same reason. A checkbox is probably the right way to handle this. While yes it's slightly more work, it does two very important things. It puts the user in control, and it is secure by default. Security is hard, and many security decisions can often have unintended impacts. I suspect in this instance, a new Fedora user (and even some old ones) will see this behavior and think one of two things. 1) It's a bug. 2) These people know NOTHING about security! Neither is an ideal outcome. Regardless of all the studies that say masking passwords doesn't help, we can't make this change quickly. We need to slowly ease people into such behavior. For now, the best solution is probably a checkbox, in a few releases we can revisit what the current accepted practice is. The current accepted practice is to mask the password, sometimes with a checkbox to unmask (but never unmask by default). I think a discussion about the merits of password masking could be had, but I'd rather not start down that path. Perhaps the better question is what problem are we trying to solve. Has anyone ever complained about Anaconda masking passwords? Thanks. -- JB -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of Hardened Packages
On Thu, Apr 11, 2013 at 12:54 PM, Reindl Harald h.rei...@thelounge.net wrote: which is exactly the goal ASLR is desigend for It's designed to make certain types of attacks more difficult. It doesn't make them impossible, just much harder. Here is an example. When you write a security exploit, you generally have to do things like call into system libraries to do useful things. Generally you have a limited amount of room for your exploit's payload, so the idea is to just leverage what the system can already do. Calling system() would be an example of this. Now long ago, before things like ASLR, if you had access to the binary you wanted to attack, you could inspect the binary to see what the address of system() was. It didn't change between runs of the binary, so I could hard code that address into my exploit. With ASLR, every time you run the binary the address of various system calls is now basically random (it's not exactly, but that's an exercise for the reader to figure out). If your payload needs to call system(), you need a way to figure out what that address is before you can use it, the added step should make it more difficult to exploit a problem. The technology isn't fool proof of course, but that's a topic for another day. Thanks. -- JB -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of Hardened Packages
On Wed, Apr 3, 2013 at 2:05 PM, Steve Grubb sgr...@redhat.com wrote: On Wednesday, April 03, 2013 01:48:17 PM Miloslav Trmač wrote: On Tue, Apr 2, 2013 at 9:57 PM, Steve Grubb sgr...@redhat.com wrote: On Saturday, March 30, 2013 08:54:30 AM Dhiru Kholia wrote: _hardened_build rpm spec macro can be used to harden a package. For an example, see http://pkgs.fedoraproject.org/cgit/clamav.git/tree/clamav.spec This flag is overly aggressive. We have a list of programs that need PIE enabled and doing more isn't necessarily constructive. Why exactly it isn't necessarily constructive? If you have hard data, please share :) Because PIE is only supposed to be on long running apps and setuid apps. If its on everything, it will slow the system down too much and then you have the knee jerk reaction to remove it from anything. We want it applied when needed and otherwise not. How much does it slow things down? I'm fairly certain you don't have any good data on this point. Dhiru is working out how to best figure out FWIW. I'm willing to agree that PIE on x86 is going to be very slow due to register pressure. However, we should consider revisiting what we want built as PIE. Is Firefox a long running process? It is on my system. Revisiting our current list and trying to understand our needs is never a bad thing to do. Existing architectures are different now than they were when that list was created, no harm comes from talking about it. -- JB -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Static Analysis: results of FUDcon Lawrence hackfest
On Thu, Jan 24, 2013 at 10:44 AM, David Malcolm dmalc...@redhat.com wrote: Anyone interested in helping with this? There's plenty of scope for getting involved: * building the web UI for dealing with the results (any Python web developers out there?) [2] * packaging more static analyzers in Fedora (e.g. has anyone looked at Frama-C ?) * writing parsers for more static analyzers * adding invocation hooks for more static analyzers to the mock-with-analysis tool * making it more robust (e.g. adding timeouts in case a tool goes into an infinite loop; recording analysis failures; etc) Can we think about finding an easy way to track these tasks? I'd love to work on some low hanging fruit in my spare time (if I ever find any), but this is currently a REALLY big idea. I mostly get this and have no clue where to start, so I suspect a new person will turn and run. Thanks. -- JB -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Revelation password manager issue
Hello all, I suspect this is going to be a weird problem to figure out. Relevation password manager https://admin.fedoraproject.org/pkgdb/applications/Revelation Password Manager Has been found to be unsafe. http://knoxin.blogspot.co.uk/2012/06/revelation-password-manager-considered.html I would hope it gets fixed at some future point, but something should probably be done in the short term. I'm not sure what Fedora precedent is on issues like this. We can't really revoke such a package, and we also want to give users a warning to use a different password manager (I'm not entirely sure how to best do this). Does anyone have any thoughts? Thanks. -- JB -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: WebKit(s) SIG
On Fri, Aug 6, 2010 at 12:11 PM, Jaroslav Reznik jrez...@redhat.com wrote: On Friday, August 06, 2010 04:45:39 pm Jaroslav Reznik wrote: If you're interested in - please reply, I'd like to start Wiki page and we can talked about more details etc. There is already WebKit page on Wiki [1] but I'd like to use this one as the entry point for users, not for more concrete technical discussion. So I created another page under SIGs category [2] (is there any policy for creation of SIGs? I wasn't very successful looking for it but I'm quite tired already). Please sign up and edit tasks section according to what do you find to be important to start SIG. It may be wise to engage the various upstream projects and other distributions for this. Even webkit upstream battles with problems as you have the two big players, Apple and Google, on different release schedules. Thanks for jumping on this, a couple of us were chatting about this just the other day, it's desperately needed. -- JB -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
