Slashdot Mirror

Its not enough to just be reactive about computer security. This still means that sophisticated attackers can hoard security vulnerabilities and develop advanced tools that find vulnerabilities the moment they are introduced. Instead, you should already design the system in a way that frustrates attacks and hopefully prevents some attacks entirely. A good talk about this:

https://www.youtube.com/watch?...

Slides:

http://outflux.net/slides/2016...

In fact you can even fix it yourself while waiting for a patch with systemtap: http://www.outflux.net/blog/archives/2012/01/22/fixing-vulnerabilities-with-systemtap/

You can build one yourself: http://outflux.net/unix/software/EPROM/

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 pro

Enjoy: http://outflux.net/geoloc/

I submitted this a while ago after reading http://www.outflux.net/blog/archives/2010/01/24/google-is-wardriving/trackback/.

As an option, but not by default. As I understand it, someone asked why SELinux wasn't in Ubuntu, and when told "nobody wants to do the work", they went and did it.

Iron Man lives!

"Get away from her, you bitch".

I use abcde for CD ripping and mp3cd for CD burning.

The only bad thing is that, currently, I still find the best application for editing commercials out of shows I want to archive, to be virtualdub [a win32 app]. It runs under wine, sure, but it still kind of hurts to have to do it. At least it's GPLd, though.

I recently dropped an Ethernet card into my TiVo, and now I can pull the video off to my Linux box directly without redigitizing from analog. After doing that, I looked for a cuts-only mpeg2 editor and found GOPchop. It took a few tries to get it to compile, but once it did, it worked out great.

I haven't completely automated the extraction process yet; basically it's currently a three step process. (1) List the filestream id numbers corresponding to a particular tyStream; (2) Start a receiver process on the Linux box using netcat; (3) extract the tyStream on the TiVo and pipe it via netcat over to the remote receiver process. It means I need to telnet to the TiVo to kick off the extraction process, instead of having a one-click interface, but it gets the job done. Oh, and I have to pipe it through tyc to convert it from the tyStream format to normal mpeg; apparently a tyStream has some extra stuff multiplexed in along with the mpeg audio and video.

I'm storing them on removable IDE drives; apparently most other folks burn video cds instead.

...another comment from Michael Tandy.