Forgot your password?
typodupeerror

Comment: Re:one of the best OSS (Score 1) 91

by fandingo (#35342332) Attached to: Book Review: Inkscape 0.48 Essentials for Web Designers

It's like an echo chamber in here today.

This past week I've been making a presentation for my coworkers, and I couldn't find any consistent images on the web that I could use. I downloaded Inkscape (Linux), and despite having absolutely zero graphical design experience, I was able to make some professional looking diagrams (at least I think they are), in just a few hours.

Most of my work required me to make small changes on one master SVG. The object "grouping" feature in Inkscape (probably from the SVG standard) was a lifesaver.

Inkscape has quickly become one of my favorite FOSS projects, and I never thought I'd being doing any sort of graphic design.

Comment: Flamebait (Score 3, Insightful) 374

by fandingo (#35318196) Attached to: Canonical To Divert Money From GNOME

This is a complete mischaracterization of what has happened. There have been several bloggers that have been outraged on the behalf the Banshee/Gnome developers, but the Banshee devs have not been upset with this decision.

In fact, the situation is far better than the summary says. First, Banshee will ship with the store enabled on Ubuntu with a 75/25 affliate split between Canonical and Gnome, respectively. Neither side has a problem with this. Second, the official Canonical music store will do a similar split (75/25), even though Gnome doesn't have anything to do with its development.

Sure, the deal sounds like shit for Gnome, especially the Banshee part, but the freaking people that develop the application weren't upset by it. Furthermore, Canonical is splitting their store.

The developers that have the right to complain about this decision aren't, so it doesn't seem like anyone else should either.

Canonical isn't perfect, but why such the hate lately? If you aren't a developer or directly related to the Gnome Foundation, STFU. Stop being outraged on other people's behalf.

Comment: Re:Apps (Score 1) 228

by fandingo (#35203984) Attached to: Intel Committed To MeeGo Despite Nokia Defection

I hope that you understand that the compiling step for a mobile application is so insignificant that no developer would care. The real differences between the mobile platforms makes "write once, run anywhere" impossible.

Screen size, aspect ratio, and resolution are just a few of the problems that cross-platform app developers have to take into account, and there's nothing that QT can do for that.

QT is a fine toolkit (I'm a big KDE enthusiast), but what are the real selling points? A comparatively small number of developers have experience with it, far less than the number of potential .Net developers for WP7. Cross-platform mobile apps are largely impossible.

Comment: Re:Yay! (Score 1) 845

by fandingo (#34955552) Attached to: The Case of Apple's Mystery Screw

I hope you understand the text and email tones for what they are. It forces conformity amongst users.
I don't have the recent update that added extras tones, but on my iPhone I have seven. Two are really terrible, leaving only five reasonable choices. That means a lot of iPhone users will use the same tone. Whenever you hear "your" tone, you instinctively think about getting a message. Furthermore, everyone else (non-iPhone users) hears these common tones, and then sees an iPhone whipped out with a nice shiny Apple logo on the back (where bystanders can see it).
The limit on non-phone call tones is a marketing decision to increase the perceived presence of the iPhone.

Comment: Re:welcome to the future (Score 1) 600

by fandingo (#34936516) Attached to: Motorola Sticks To Guns On Locking Down Android

Exactly. And furthermore, even if all the authors changed their license, Google and Co. would still have the previous release under the current license: GPLv2.

Many people who were critical of the Oracle buyout of Sun with respect to MySQL favored this exact same approach. The difference was a worry by the community that Oracle would (and who knows, might still) make MySQL less free. The interesting part about this is that Google and phone manufactures want a different kind of "freedom." The community wants copyleft licenses like the GPL because it preserves the community's access to code. Developers would rather use something closer to BSD where they can pick and choose what source is distributed.

Sure a GPLv3 Android (either through direct license or forced sub-system license) would be great for the community. However, I think that would destroy the very manufacturers that make Android possible.

I can't say that I happy with manufactuer's and Google's practices with releasing devices before open source code (like the GPL'd kernel). However, I'd say the situation is okay. There's not much that can be done about it, so I don't get too worked up about it.

Comment: Re:Yes, as I've said many times.... (Score 2) 456

by fandingo (#34897914) Attached to: Why Linux Loses Out On Hardware Acceleration In Firefox

I'm using Fedora 14 with testing repos. I'm currently running KDE SC 4.5.96 (KDE SC 4.6 RC2) with Nvidia 260.19.29 (card is a GeForce 210), and I haven't had any problems. I use compositing with Kwin too, and don't have any slowness or crashing.

I don't doubt that other people have had problems, but it's certainly not universal.

Graphics drivers on Linux are a complete mess, unless you use the Nvidia proprietary drivers. I'm not sure why anyone would choose anything else if they care about performance or features. There's just no comparison.

Comment: Dropping SUID doesn't improve security (Score 5, Informative) 122

by fandingo (#34592874) Attached to: Openwall Linux 3.0 — No SUIDs, Anti-Log-Spoofing

Here's one of the better criticisms of dropping SUID, and it's from an Openwall developer. These criticisms are echoed by almost everyone thinking about removing SUID.

There's a lot of talk lately regarding replacing the SUID bit on program
binaries in Linux distros with filesystem capabilities. Specifically,
Fedora and Ubuntu are heading in that direction.

Fedora:
http://fedoraproject.org/wiki/Features/RemoveSETUID
https://bugzilla.redhat.com/show_bug.cgi?id=646440

Ubuntu:
http://www.outflux.net/blog/archives/2010/02/09/easy-example-of-fscaps/
https://wiki.ubuntu.com/Security/FilesystemCapabilties

While in general this is a good idea, there are issues with it, in
arbitrary order:

- Some currently-SUID programs are aware of them being (potentially)
SUID, and will drop the "more privileged" euid when it is no longer
needed, but they will probably not be aware of them possessing
capabilities. This may result in larger parts of the programs
(sometimes orders of magnitude larger) running with elevated privileges
(or with allowed-to-be-elevated privileges, which is a privilege on its
own and is usable through vulnerabilities that allow for arbitrary code
execution). Let's consider ping, which appears to be the classical
example of "where filesystem capabilities will help" (or so it is
claimed). IIRC, it starts by acquiring a raw socket (NB: of a certain
somewhat-limited type), then drops root privs (if it was installed SUID
root and run by non-root), then proceeds to parse the command-line,
resolve the provided hostname, and so on. If the SUID bit is replaced
with cap_net_raw+ep, as seen in Kees' example above, will ping know to
drop this capability? Hardly. Not without a source code patch.
Besides, dropping the capability might [need to] require privileges
beyond CAP_NET_RAW itself (recall the capability-dropping attack on
sendmail from a decade ago). So does moving from SUID root to
cap_net_raw+ep improve security? Most likely not. On the contrary, it
results in hundreds of lines of ping's code and thousands of lines of
library code (DNS resolver) running with elevated privileges, as
compared to just a few lines of ping.c, which was the case with simple
SUID root. Granted, those "elevated privileges" are a lot less than
root privileges, but they're a lot more than having a single raw socket
of a specific type.

- In some cases, the capability sets being granted are (almost)
equivalent (or expandable to) full root powers. This is seen in:

http://people.fedoraproject.org/~dwalsh/policycoreutils_setuid.patch

-%attr(4755,root,root) %{_bindir}/newrole
+%attr(0755,root,root) %caps(cap_audit_write,cap_setuid) %{_bindir}/newrole

-%{_sbindir}/seunshare
+%attr(0755,root,root) %caps(cap_setuid,cap_dac_override,cap_sys_admin,cap_sys_nice) %{_sbindir}/seunshare

This mostly just sweeps the SUID root under the rug, where the sysadmin
will hopefully not see it and thus feel safer. However, it may expose
more problems in the programs if they knew to drop root, but wouldn't
know to drop the capabilities (same issue I described above for ping).

Granted, vulnerabilities of certain classes might become unexploitable
or be partially mitigated. For example, if no direct code execution is
possible (not a buffer overflow, etc.), but "only" privileged access to
an attacker-provided arbitrary pathname is possible, then "newrole"
above would be protected, but "seunshare" above would not (because of
cap_dac_override).

- Completely getting rid of SUID root programs in the default install,
like we did in Owl-current (but without filesystem capabilities!), is a
great idea. It mitigates the impact of possible vulnerabilities in
certain code paths in the dynamic linker, libc, and the kernel.
However, if you have even a single SUID root program left, you do not
achieve this goal. Thus, switching from SUID root to CAP_NET_RAW for
ping, with its tiny and obviously-correct code that used to run as root,
gives you absolutely nothing as long as you keep su and/or sudo
available for invocation (not necessarily actual use) by all users.

For servers, I think people need to reconsider and, in most cases,
disallow invocation of su and sudo by the users. There's no added
security from the old "login as non-root, then su or sudo to root"
sysadmin "wisdom", as compared to logging in as non-root and as root
directly (two separate sessions). On the contrary, the latter approach
is the only correct one, from a security standpoint:

http://www.openwall.com/lists/owl-users/2004/10/20/6

(For accountability of multiple sysadmins, the system needs to support
having multiple root-privileged accounts, like Owl does.)

(For desktops with X, this gets trickier.)

You also absolutely have to deal with passwd, which would be another
SUID root program. Like we did:

http://www.openwall.com/tcb/

And with all others (e.g., our crontab/at and crond changes). :-)

- Support for filesystem capabilities and extended attributes is still
not mature. Many userspace tools (such as for backup/restore) lack it.

Thus, if you must, it might make sense to use a poor man's replacement,
which will be more reliable. Introduce a sysctl to configure a groups
range to map onto capabilities. With 32 or 64 group IDs allocated for
the purpose, you can have any one capability set.

I briefly experimented with just that on a Slackware 3.1
system with capabilities support patched into the 2.0.x kernel, with the
caps-by-gid changes hacked into the kernel on top of the capabilities
patch on my own. That was in 1998 or so. The conclusion was that
without userspace patches this would achieve too little.

With 1024 or 4096 IDs (or 992 or 4032 with a smarter approach), you can
have any two caps. 32-bit GIDs permit you to have up to 5 or 6 caps
simultaneously in this way. I think that in practice 1 or 2 caps will
be enough; the cases where you'd assign more are typically the ones
where the caps are (almost) equivalent to root anyway.

This is more reliable in several aspects:

* The SGID bit and st_gid are stored/restored by all existing Unix
backup/restore/copy/packaging tools.

* Such programs are easy for a sysadmin to identify with the familiar
options to "find", etc.

* Programs either already know to drop the "elevated" egid or are easy
to teach to do so (and the kernel patch may include logic to drop
egid-granted caps when the egid is dropped). This does not require
privileges on its own. And that fact will not confuse any correct but
old program (no "sendmail risk").

- For ping in particular, we've been considering another approach -
namely, a new socket type (non-raw ICMP, similar to the usual UDP
sockets). This would eliminate the need for ping to run with elevated
privileges, or we could introduce some privilege boundary (SGID to some
sysctl'able ICMP-socket-enabling group) just not to expose potential
vulnerabilities in the added kernel code. We have a Linux 2.4.x patch
and a ping patch to implement this, both by Pavel Kankovsky. It's my
fault this never actually got into Owl (so far); I ran out of time.
Any volunteers to update this to Linux 2.6.x, introduce the sysctl, and
actually make use of it in a distro? Please let me know.

Thanks for reading this far, and I'd appreciate any comments and/or
corrections. Some of the info above might be outdated - e.g., I am not
sure of what current kernels require (or not) to drop capabilities.
(If they no longer require anything extra to drop CAP_SETUID, then
that's a security problem on its own - the "sendmail risk" is back.)

Alexander
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

BTW Fedora 15 is also dropping SUID, so while Openwall is the only current distro. It's by no means the only one in development. Ubuntu is also removing SUID, but I don't know their timetable.

Comment: Re:So it works the way Stallman envisioned? (Score 1) 191

by fandingo (#34453676) Attached to: Paid Developers Power the Linux Kernel

This is incorrect on two levels. First, you only need to make the changes available if you distribute the changed code to outside parties. Second, you only have to make the changes to those outside parties, not the general public. However, those parties are free to redistribute it, so this really depends on your customers.
At my company, we have modified several GNU tools, and we haven't released any source code because we use them internally.

Personally, I favor BSD-style licenses over GPL. Yet, for internal applications there's very little difference. BSD just allows redistribution without source code.

Comment: Re:Shortcuts (Score 1) 394

by fandingo (#34014544) Attached to: Bees Beat Machines At 'Traveling Salesman' Problem

Actually, it doesn't. Yes, it takes "time" for humans/bees/whatever to calculate the lowest cost route, but when studying algorithms, it doesn't add anything to the complexity. Since finding the quickest route is really like sorting, you get O(n Log(n)) which is contained in P.

Back to TSP, the additional routes don't even matter, because it's illogical to ever take an inefficient path.

Comment: Re:ITT: "Get off my lawn" (Score 3, Interesting) 617

by fandingo (#33789778) Attached to: Take This GUI and Shove It

I don't think you really understand systems administration. 'Users,' or in this case admins, don't typically do stuff once. Furthermore, they need to know what he did and how to do it again (i.e. new server or whatever) or just remember what he did.
One-off stuff isn't common and is a sign of poor administration (i.e. tracking changes and following processes).

What I'm trying to get at is that admins shouldn't do anything without reading the manual. As a Windows/Linux admin, I tend to find Linux easier to properly administer because I either already know how to perform an operation or I have to read the manual (manpage) and learn a decent amount about the operation (i.e. more than click here/use this flag).

Don't get me wrong, GUIs can make unknown operations significantly easier, but they often lead to poor process management. To document processes, screenshots are typically needed. They can be done well, but I find that GUI documentation (created by admins, not vendor docs) tend to be of very low quality. They are also vulnerable to 'upgrades' where vendors change the interface design. CLI programs typically have more stable interfaces, but maybe that's just because they have been around longer...

+ - Nokia CEO- Android like peeing in pants for warmth->

Submitted by teh31337one
teh31337one (1590023) writes "Outgoing Nokia Exec Anssi Vanjoki has likened manufacturers who've embraced Android, to Finnish kids who "pee in their pants" for warmth during the winter, claiming it won't pay-off in the long run.

The big question facing Nokia has been: should the company give up on its own software and put Google’s Android operating system on its phones instead? Combining Nokia’s great hardware with Google’s software could do wonders for sales. As for margins, Nokia sinks a tenth of its handset division’s revenue into research and development, three times as much as Apple. UBS reckons Nokia could cut annual R&D spending by about €1bn a year if it stopped working on software, lifting the division’s operating margin by 400 basis points."

Link to Original Source

"Religion is something left over from the infancy of our intelligence, it will fade away as we adopt reason and science as our guidelines." -- Bertrand Russell

Working...