gmane.linux.gentoo.hardened

Re: tg3 driver - transmit timed out, resetting

David Sommerseth — 2008-11-28T15:56:28

Hmmm ... No, I have not had that opportunity. The server is located 2000km away from me, and I usually call a guy (who is not a technician)to go in and press CTRL-ALT-DEL on a keyboard. That is the short-time "fix". But I'm going to have a look physically on the server in a couple of weeks, so if I get positive feedbacks from others as well regarding 2.6.27 kernel, I'm willing to try that upgrade. This interface is an on-board interface in an IBM eServer. The first time it happened, it was no problems for about 28 days. Now it was 13 days. So I expect it to happen again, soon enough. I'll try to hack the shutdown scripts to dump the ifconfig info somewhere somehow. kind regards, David Sommerseth

Re: tg3 driver - transmit timed out, resetting

2008-11-28T14:02:00

PCI-X dual port Broadcom NetXtreme BCM5704 Gigabit Ethernet (rev 03) adapter is working fine here driven by tg3, 2.6.27-hardened-r1. The driver doesn't seem to be borked with my card. Did you check out the "error" field of ifconfig's output for the interface of your card? Regards, Dw.

tg3 driver - transmit timed out, resetting

David Sommerseth — 2008-11-28T13:28:15

Hello Folks! Maybe some of you have seen this before, or know something ... I have a Broadcom NetXtreme card which have locked up twice within 13 days. I upgraded to the 2.6.25-hardened-r8 kernel mid-october, and have a feeling this upgrade introduced this issue. Before that I was linux-2.6.22-hardened-r8 for over a year without any problems. The log entries from both episodes are identical. Any hints? Are there any safe 2.6.26 or 2.6.27 kernels available? kind regards, David Sommerseth ---------------------------------------------------------------------------- 06:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express (rev 21) Subsystem: IBM eServer xSeries server mainboard Flags: bus master, fast devsel, latency 0, IRQ 219 Memory at d8200000 (64-bit, non-prefetchable) [size=64K] Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ Queue=0/3 Enable+ Capabilities: [d0] Express Endpoint, MSI 00 Kernel driver in use: tg3 ---------------------------------------------------------------------------- tg3.c:v3.91 (April 18, 2008) ---------------------------------------------------------------------------- Nov 28 12:47:34 linuxbox [51195.788361] NETDEV WATCHDOG: eth0: transmit timed out Nov 28 12:47:34 linuxbox [51195.788424] tg3: eth0: transmit timed out, resetting Nov 28 12:47:34 linuxbox [51195.788464] tg3: DEBUG: MAC_TX_STATUS[ffffffff] MAC_RX_STATUS[ffffffff] Nov 28 12:47:34 linuxbox [51195.788500] tg3: DEBUG: RDMAC_STATUS[ffffffff] WDMAC_STATUS[ffffffff] Nov 28 12:47:34 linuxbox [51195.899576] tg3: tg3_stop_block timed out, ofs=2c00 enable_bit=2 Nov 28 12:47:34 linuxbox [51196.004849] tg3: tg3_stop_block timed out, ofs=2000 enable_bit=2 Nov 28 12:47:34 linuxbox [51196.110115] tg3: tg3_stop_block timed out, ofs=2400 enable_bit=2 Nov 28 12:47:34 linuxbox [51196.215378] tg3: tg3_stop_block timed out, ofs=2800 enable_bit=2 Nov 28 12:47:34 linuxbox [51196.320655] tg3: tg3_stop_block timed out, ofs=3000 enable_bit=2 Nov 28 12:47:34 linuxbox [51196.425925] tg3: tg3_stop_block timed out, ofs=1400 enable_bit=2 Nov 28 12:47:34 linuxbox [51196.531191] tg3: tg3_stop_block timed out, ofs=1800 enable_bit=2 Nov 28 12:47:35 linuxbox [51196.636469] tg3: tg3_stop_block timed out, ofs=c00 enable_bit=2 Nov 28 12:47:35 linuxbox [51196.741735] tg3: tg3_stop_block timed out, ofs=4800 enable_bit=2 Nov 28 12:47:35 linuxbox [51196.847001] tg3: tg3_stop_block timed out, ofs=1000 enable_bit=2 Nov 28 12:47:35 linuxbox [51196.952267] tg3: tg3_stop_block timed out, ofs=1c00 enable_bit=2 Nov 28 12:47:35 linuxbox [51197.057655] tg3: tg3_abort_hw timed out for eth0, TX_MODE_ENABLE will not clear MAC_TX_MODE=ffffffff Nov 28 12:47:35 linuxbox [51197.162912] tg3: tg3_stop_block timed out, ofs=3c00 enable_bit=2 Nov 28 12:47:35 linuxbox [51197.268179] tg3: tg3_stop_block timed out, ofs=4c00 enable_bit=2 Nov 28 12:47:38 linuxbox [51199.841388] tg3: eth0: No firmware running. Nov 28 12:47:39 linuxbox [51201.105071] tg3: tg3_abort_hw timed out for eth0, TX_MODE_ENABLE will not clear MAC_TX_MODE=ffffffff Nov 28 12:47:59 linuxbox [51221.133560] tg3: eth0: Link is down. Nov 28 13:09:03 linuxbox [51330.696020] tg3: tg3_abort_hw timed out for eth0, TX_MODE_ENABLE will not clear MAC_TX_MODE=ffffffff ------------------------------------------------------------------------

Re: hardened workstation - is that worth it?

7v5w7go9ub0o — 2008-11-26T17:41:04

Sigh... yes, it becomes murky for me beyond 2.6.26. I'm presently using patch-dazuko-linux-2.6.25.diff.gz on hardened-sources-2.6.25-r10, and don't have any experience with redirfs or dazukofs. ISTM there is now (finally) a LOT of interest in real-time file access control, along with competing approaches including dazuko, dazukofs, redirfs, and "libmalware.so" (under discussion at kerneltrap). Things I'd like to pursue :-) : 1. Signature and heuristic scanning of anything that downloads into my box, or anything that may be compiled from otherwise innocent looking code. Dazuko/Antivir provides that now. 2. "whitelist" scanning. This would be a realtime "integrity management system" challenge/update. So if, for e.g., the MD5 of an LKM or other system file changed, the scanner would stop, popup, and challenge the validity of the modified LKM. 3. "changed folder" monitoring. e.g. if I get activity in a usenet application, I could get a popup and "beep".

Re: hardened workstation - is that worth it?

7v5w7go9ub0o — 2008-11-26T17:31:09

I set this up three+ years ago, and after initial setup, it's been really easy to maintain. Every now and then I have to "retrain" RBAC, but I use a training script to do that, so it is pretty automatic as well I've not had anything break G+P+T. - I had pax continuously cancel FireFox on a particular site a few years ago, and never figured out what it was. It might hae been a browser attack, or it may have simply been a badly-written extension. I now browse with Opera (in a jail), and use Firefox ("fox in a box") in a limited way. - I also today real-time scan the browser jails (which I run in ramdisk, so that any unintended changes are discarded at the end of the session) with Dazuko/Antivir, and have had a number of suspicious scripts blocked by AntiVir before the browser could act on them - so I think that my exposure is thereby reduced. Well, that's a good point - it can be a pain, e.g. copying a document into the mail client chroot jail so that I can send it. I also use numerous, individual, single-purpose users (e.g. ooffice:ooffice;, opera:opera, tbird:tbird, etc.) so that, e.g., user/jail wireshark:wireshark can not read user tbird:tbird, and vice versa. This can be a pain because I need to change privilege, as well as copying things into - e.g., the tbird jail. Copying downloads out of jails is easy - a script copies all downloads from the various jails into a single folder, which is then scanned for Trojan signatures.

Re: hardened workstation - is that worth it?

Jan Klod — 2008-11-26T11:39:22

Gives nothing, if all ways outside (network, no plaintext filesystems!) are closed and sessions are secure (locked, if not legitimately operated in AND enough bug-free). Yes, but who is going to work on disconnected system? Adding some kind of proxy with firewall opens up a possibility of malicious transfer to some trusted outside service, which can theoretically be compromised by then. Also I didn't count some wild tricks with operating hardware... But that doesn't count, as RAM can be partially read by coldboot att. My problem is stupidly simple: I just want a safe (well, as safe as possible) way to exchange my mails. If I leave my physical hardware to be "as safe as possible", outside channel to mailserver remains (and can then once become a tunnel for other information). Anything, that would allow to leak information through network or wipe local files, which is not an exact list of things, of course. I would appreciate, if someone throws in a link(s) to where people show / discuss ways it could be done, even if Linux user is careful (but not "paranoid") about how he uses the system. Sure.

Re: Re: hardened workstation - is that worth it?

2008-11-26T06:09:47

patch-dazuko-2.6.26 cannot be applied on 2.6.27 any more, because of some API changes. There are signs of a redirfs-based patch for 2.6.27. I haven't downloaded it, yet. Upstream pushes dazukofs. What type of dazuko setup do you use? What are your experiences with redirfs or dazukofs? Regards, Dw.

Re: Re: hardened workstation - is that worth it?

Alex Efros — 2008-11-26T02:34:21

Hi! On Tue, Nov 25, 2008 at 09:02:58PM -0500, 7v5w7go9ub0o wrote: Wow. While I'm a paranoiac in this sense too, I'm too lazy to do most of these things. It's good to know there are potential for me to advance on this way! ;-) BTW, is your workstation really was under attack (don't counting ssh worms and the like script kiddie games)? Is there was attacks which was able to break first circle of protection (GrSec+PaX+toolchain)? As for me, I decide not to worry about these things (browser chroot, etc.) for now because on workstation most important information is files in my home directory... and applications I use (like browser, mail client, etc.) MUST have access to these files or these applications because nearly unusable for me. So, even with RSBAC, if my mutt will be owned by some malicious email, and it will delete/damage files it usually have access to (like my mailbox :)), that will be _enough_ and make much more damage for me than installing rootkit. So, I choose to do regular automated backups and run chkrootkit/rkhunter from cron just for the case they detect something interesting to play with. :)

Re: hardened workstation - is that worth it?

7v5w7go9ub0o — 2008-11-26T02:02:58

Depends upon your definition of hardening, I guess. I run the "old" hardened toolchain, grsecurity-enhanced hardened kernel, rbac control, and jails for anything that accesses the LAN/WAN.(heh... I even chroot and kill dhcpcd after 5 seconds). Avira has hundreds of Linux rootkit signatures in its database, so I run Avira and Dazuko realtime/on-access scanning on my /home directory, the chroot jails, and on the portage workspace used during download and compilation. I presume that for a desktop user, most attacks come in through the browser, and/or extensions, plugins (e.g. flash), BHO's, etc. Something could also come through the distribution chain from a compromised or spoofed source - therefor the signature scanning. - I presume that pax and/or ssp will protect me against memory attacks that may come in through a L/WAN connection. - If the L/WAN attack comes in through, say, a browser exploit or backdoor it will be confined by RBAC to the areas I trained it to access, and no more. That would be the jail. - If the browser tries to "jail break", it will run up against the anti jailbreak hardening provided by grsecurity, and be terminated. - grsecurity blocks writing to /dev/mem, kmem, port. Judging by the other posts here, someone who knows what he is doing can have my box. Well..... yes! - nothing is 100%. But I'm not trying to protect against him.... I'm worried about 95%: the 0-day browser bugs, compromised extensions, etc. that may allow a Trojan to try its stuff, or may allow an inpatient script-kiddee to have a shell on a Linux box that doesn't have this kernel and binary hardening; that doesn't run applications in hardened jails.

Re: hardened workstation - is that worth it?

Javier Martínez — 2008-11-25T23:23:33

Why are the bit root-suid applications a risk in the point of view of security? The X server is a root-setuid binary that can't be assured from the point of view of posix capabilities for example, the reason is clear one process that has only CAP_SYS_RAWIO capability could make raw writing in /dev/mem!!!. Before the filesystem capabilities one process with only CAP_SYS_RAWIO and the others restricted could add all others capabilities missing by simply searching the cap_bset in their system.map and writting 0xFFFFFEFF in it through /dev/mem. With this hack he has CAP_SYS_SUID CAP_SYS_SGID, CAP_DAC_OVERRIDE etc..., now with the filesystem capabilities probably you could do the same by writting in the task_struct of the process. Xorg is worst than a normal setuid program, ping for example could be assured granting only CAP_NET_RAW, with this privilege ping can't own the rest of the system. Xorg can't be assured, it needs CAP_SYS_RAWIO and CAP_DAC_OVERRIDE between others, enough to write /dev/mem). Xorg adds one level of complexity unaceptable from a security view point, it's something like sendmail, how could you make sendmail more secure?, rewritting it from 0!!!! Xorg was not designed to be secure, only to networking. Patches has been added (as xace extensions) to make it a bit more secure, but it stills insecure (if you dress a monkey to be saw as a human, it stills being monkey!!). Xorg mmaps video memory through /dev/mem and I think that the way it does it is which make it incompatible with PaX mprotect restrictions (pax author could tell you more), so is a problem of Xorg, not PaX does simply does his job kill Xorg. Complexity and security are enemies, and if complexity is added to a bad design then switch off. In my opinion having 3 or 300 holes is irrelevant from a security view point, with only one is enough!. Any programmer with a bit of known of assembly could make exploits, and as phrack made in one of his articles, one great programmer with deep knowledge of memory management and PaX could even defeat it. 2008/11/25 Jan Klod public.gmane.org>:

Re: hardened workstation - is that worth it?

RB — 2008-11-25T22:14:47

That's kind of outside the realm of this discussion. The difference between the attack surface of a network interface versus that of a local application is several orders of magnitude. Local applications have filesystems, local sockets, shared memory, hardware, and many other channels they can use to communicate with and subvert others, whereas a system that is simply networked has a single point of entry. The problem, as I see it, is that you haven't defined your problem scope. Taking "extra precautions" is nice, but unless you [even broadly] classify what you consider a viable threat, you're not going to gain much ground. My advice would be to sit back and try to define what you're defending against. There are measures you can take, but blindly applying security policies is more likely to end up with a broken system than a secure one.

Re: hardened workstation - is that worth it?

2008-11-25T22:11:52

Dear Jan, On Ked, November 25, 2008 22:58, Jan Klod wrote: IMHO: not useless. Perfect security is non-existent. But there can be some systems that are more secure compared to others. One should seek after the highest achievable security in a particular case. Have you heard the joke about the two monks wandering in the desert? No? Suddenly a lion appears in the distance. One of the monks stops and starts to put on a pair of running shoes. The other starts arguing: "Let's get moving! We should start running. How fool you are! Do you think you are faster than the lion if you wear those shoes?" The other replies: "I don't have to be faster than the lion. I just have to be faster than you..." Regards, Dw.

Re: hardened workstation - is that worth it?

Jan Klod — 2008-11-25T21:58:06

Actually, that sound like there is practically no way to keep networked workstation really secure. Sure, is not trivial to gain root access through software bugs (interesting, how many list member would be able to do it?), but no one running X can claim, he has absolutely secure system, which can't fail him regardless to who is the hacker. Furthermore, the system is said to be only as secure as the weakest part, so making hardened server will only slow down attacks and, at most, ensure server stability. Still, if there is someone ready to attack servers end clients (which ones will almost always have X running), the way can be open. Can someone explain how would it happen, the exploitation of buffer overflow in X? How would attacker gain access to X bug most importantly? What are those ways for other apps? Always different? And have there been any efforts to make PaX enabled X? Personally, I think, the best way would be using firewall to allow only the most necessary addresses, which point to trusted services (mail,sftp,...). That said, web browsing is cut off. As a conclusion of what I have read this far I can state: hardened OS is useless for non-server. Would that be too much? Well, I think, in a "black and white" no. (later is a discussion of what is better: to have 3 holes or 300) Comments?

Re: hardened workstation - is that worth it?

RB — 2008-11-25T21:47:36

On my part, none. All my hardened boxes are headless servers and my GUI workstations have disposable configurations. Even if stepping away from a window manager and all its associated programs, you still have X and the numerous associated security holes (Javier outlined those well). For keyloggers, X is designed so that any application you allow to connect to it can capture any of your keystrokes. That means that regardless of whether you're running X as user1, google earth as user2, and firefox as user3, both of those applications can pick up all of your keystrokes. Since you're running as separate users, you have already (implicitly or not) allowed those users to freely connect to your X session. Game over. X and window managers used to be much more unfriendly, you had to do things like 'xhost +root< at >localhost' to allow root to pop up an Nmap GUI. Now, they all handle those things behind the scenes and for the most part get it right for the large majority of users. This is our reality as desktop Linux tries to appeal to a broader audience.

Re: hardened workstation - is that worth it?

Jan Klod — 2008-11-25T21:24:56

Please, I would like to see some more explanation about it! What do you mean by it?

Re: hardened workstation - is that worth it?

Jan Klod — 2008-11-25T21:12:32

Well, then I would like to ask your opinion about other available window managers. Any better solutions in a direction "stupid and safe"?

Re: hardened workstation - is that worth it?

Alex Efros — 2008-11-25T20:56:59

Hi! On Tue, Nov 25, 2008 at 09:51:09PM +0100, Javier Martínez wrote: Yeah, that's true, I forget about RSBAC-like things when wrote about 2-5% slowdown. My benchmarks was about GrSec + PaX + hardened toolchain, without any access control systems like RSBAC or SeLinux.

Re: hardened workstation - is that worth it?

Javier Martínez — 2008-11-25T20:51:09

Benchmarks are very relative, one RSBAC system logging all READ/READ_OPEN requests made (granted or not) is something like a turtle. They depend how did you configure your system.

Re: whitelist of apps granted network access?

Javier Martínez — 2008-11-25T20:44:34

RSBAC permits network access control. Maybe you could do what you are looking for with the RC model 2008/11/25 public.gmane.org>:

Re: hardened workstation - is that worth it?

Alex Efros — 2008-11-25T20:40:49

Hi! On Tue, Nov 25, 2008 at 06:39:26PM +0200, Jan Klod wrote: Most of this already done by portage when emerging apps, so you rarely need to do this manually. Few examples come in my mind is operawrapper for running complex Flash/Flex applications; mplayer for playing files in windows-related formats using codecs in .dll (media-libs/win32codecs); and OS Inferno which is virtual machine like Java but compiled manually (probably I'll create ebuild for it later). Also you have to switch off one item in kernel configuration (compared to typical config on servers): Security options ---> Grsecurity ---> Address Space Protection ---> [ ] Disable privileged I/O and may need to enable loadable modules support (also switched off on servers) to work with VMware or binary NVidia drivers etc. There some available on internet, just google for it. AFAIR there was 2-5% slowdown compared to non-hardened system. I did my own tests several years ago when switching to hardened - same results: 2% slowdown for most operations, compiling a little more slower. Nothing noticeable on workstation to worry about unless you have ancient hardware which play mp3s using 100% CPU and will lag if you do anything else at same time. :)

Re: hardened workstation - is that worth it?

Javier Martínez — 2008-11-25T20:36:22

He always could keep running X-window and his window manager (both) in a chrooted environment, he just protect extremely /dev/mem. Maybe he would not need /proc filesystem. If security is important why don't keep running the Xserver isolated (in a virtualbox for example and hardened with rsbac) and remote users get logged in with xnest through a ssl tunnel?. With those you get your untrusted users isolated from main system. In my opinion getting X-window running is bad in security concerns, by this reasons: - First: PaX should be disable in mprotect terms since Xorg needs it (with it refuse to run) . - Second: Access to /dev/mem have to be granted and get in mind that CAP_SYS_RAWIO capability (between others) too, for this reason, one bug in Xserver will give all control to the attacker (and keep in mind that with access to /dev/mem all Selinux, rsbac and grsecurity policies are wasted efforts). Since mprotect protections have to be disabled pax could not protect you. - Third: You must assure the access to the display, to make a keylogger in x-window is easy if there is posibility to connect untrusted clients to it. 2008/11/25 RB public.gmane.org>: