[gentoo-hardened] hardened workstation - is that worth it?

[gentoo-hardened] hardened workstation - is that worth it?

[Jan Klod]

Suppose, I want to take some extra precautions and set up PaX&co and MAC on a 
workstation with Xorg and other nice KDE apps (only some of which should be 
granted access to files in folder X). I would like to read others opinion, if 
I can get considerable security improvements or I will have to make that much 
of exceptions to those good rules, as it makes protection too useless?

Regards,
Jan

Re: [gentoo-hardened] hardened workstation - is that worth it?

[Alex Efros]

Hi!

On Tue, Nov 25, 2008 at 05:00:45PM +0200, Jan Klod wrote:
> Suppose, I want to take some extra precautions and set up PaX&co and MAC on a 
> workstation with Xorg and other nice KDE apps (only some of which should be 
> granted access to files in folder X). I would like to read others opinion, if 
> I can get considerable security improvements or I will have to make that much 
> of exceptions to those good rules, as it makes protection too useless?

Not sure about MAC, but GrSec + PaX + hardened toolchain is nice to have.
Unlike MAC, it's ease to setup, and there only few applications require
some weakening of security (using paxctl).
I use hardened workstation configured this way for years.

You can improve security further by running applications like web browser
and e-mail client in chroot, but that's for true paranoiac. :)

-- 
			WBR, Alex.

Re: [gentoo-hardened] hardened workstation - is that worth it?

[Jan Klod]

On Tuesday 25 November 2008 17:56:41 Alex Efros wrote:
> Hi!
>
> On Tue, Nov 25, 2008 at 05:00:45PM +0200, Jan Klod wrote:
> > Suppose, I want to take some extra precautions and set up PaX&co and MAC
> > on a workstation with Xorg and other nice KDE apps (only some of which
> > should be granted access to files in folder X). I would like to read
> > others opinion, if I can get considerable security improvements or I will
> > have to make that much of exceptions to those good rules, as it makes
> > protection too useless?
>
> Not sure about MAC, but GrSec + PaX + hardened toolchain is nice to have.
> Unlike MAC, it's ease to setup, and there only few applications require
> some weakening of security (using paxctl).
> I use hardened workstation configured this way for years.

Could you post a list of apps, that need PaX lifted?

Also there is another question: has anyone made some benchmarks to see how 
much raw computing power (CPU+RAM access, which happen during some purely 
computational task) decreases?

Re: [gentoo-hardened] hardened workstation - is that worth it?

[RB]

On Tue, Nov 25, 2008 at 08:00, Jan Klod <janklodvan@gmail.com> wrote:
> Suppose, I want to take some extra precautions and set up PaX&co and MAC on a
> workstation with Xorg and other nice KDE apps (only some of which should be
> granted access to files in folder X). I would like to read others opinion, if
> I can get considerable security improvements or I will have to make that much
> of exceptions to those good rules, as it makes protection too useless?

KDE (and to a lesser extent X) pretty much nullifies most application
isolation efforts you're going to make.  Even if you ran each
application under a dedicated user and in its own chroot environment,
the GUI provides IPC facilites that will readily bypass all your hard
effort.  As with your other email, clicking a link in one app opens a
browser window in another, regardless of what user separation you
might have - KDE does this under the covers, since it's what most
users would actually want, but you perceive it as a security breach.

"Extra precautions" is incredibly nebulous and you won't get much help
in security circles unless you have specific, addressable concerns.
You can do all the hardening you want, but generally speaking the more
user-friendly and complex your system is the more security concessions
you are going to have to make.

Re: [gentoo-hardened] hardened workstation - is that worth it?

[Javier Martínez]

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 <aoz.syn@gmail.com>:
> On Tue, Nov 25, 2008 at 08:00, Jan Klod <janklodvan@gmail.com> wrote:
>> Suppose, I want to take some extra precautions and set up PaX&co and MAC on a
>> workstation with Xorg and other nice KDE apps (only some of which should be
>> granted access to files in folder X). I would like to read others opinion, if
>> I can get considerable security improvements or I will have to make that much
>> of exceptions to those good rules, as it makes protection too useless?
>
> KDE (and to a lesser extent X) pretty much nullifies most application
> isolation efforts you're going to make.  Even if you ran each
> application under a dedicated user and in its own chroot environment,
> the GUI provides IPC facilites that will readily bypass all your hard
> effort.  As with your other email, clicking a link in one app opens a
> browser window in another, regardless of what user separation you
> might have - KDE does this under the covers, since it's what most
> users would actually want, but you perceive it as a security breach.

Re: [gentoo-hardened] hardened workstation - is that worth it?

[Alex Efros]

Hi!

On Tue, Nov 25, 2008 at 06:39:26PM +0200, Jan Klod wrote:
> Could you post a list of apps, that need PaX lifted?

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.

> Also there is another question: has anyone made some benchmarks to see how 
> much raw computing power (CPU+RAM access, which happen during some purely 
> computational task) decreases?

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. :)

-- 
			WBR, Alex.

Re: [gentoo-hardened] hardened workstation - is that worth it?

[Javier Martínez]

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.

> Also there is another question: has anyone made some benchmarks to see how
> much raw computing power (CPU+RAM access, which happen during some purely
> computational task) decreases?
>
>

Re: [gentoo-hardened] hardened workstation - is that worth it?

[Alex Efros]

Hi!

On Tue, Nov 25, 2008 at 09:51:09PM +0100, Javier Martínez wrote:
> 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.

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.

-- 
			WBR, Alex.

Re: [gentoo-hardened] hardened workstation - is that worth it?

[Jan Klod]

On Tuesday 25 November 2008 19:58:42 RB wrote:
> KDE (and to a lesser extent X) pretty much nullifies most application
> isolation efforts you're going to make.

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

Re: [gentoo-hardened] hardened workstation - is that worth it?

[Jan Klod]

On Tuesday 25 November 2008 20:36:22 Javier Martínez wrote:
> to make a
> keylogger in x-window is easy if there is posibility to connect
> untrusted clients to it.

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

Re: [gentoo-hardened] hardened workstation - is that worth it?

[RB]

On Tue, Nov 25, 2008 at 14:12, Jan Klod <janklodvan@gmail.com> wrote:
> On Tuesday 25 November 2008 19:58:42 RB wrote:
>> KDE (and to a lesser extent X) pretty much nullifies most application
>> isolation efforts you're going to make.
>
> Well, then I would like to ask your opinion about other available window
> managers. Any better solutions in a direction "stupid and safe"?

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@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: [gentoo-hardened] hardened workstation - is that worth it?

[Jan Klod]

On Tuesday 25 November 2008 19:58:42 RB wrote:
> KDE (and to a lesser extent X) pretty much nullifies most application
> isolation efforts you're going to make.

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: [gentoo-hardened] hardened workstation - is that worth it?

[atoth]

Dear Jan,

On Ked, November 25, 2008 22:58, Jan Klod wrote:
> 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

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: [gentoo-hardened] hardened workstation - is that worth it?

[RB]

On Tue, Nov 25, 2008 at 14:58, Jan Klod <janklodvan@gmail.com> wrote:
> Actually, that sound like there is practically no way to keep networked
> workstation really secure.

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.

> 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)

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: [gentoo-hardened] hardened workstation - is that worth it?

[Javier Martínez]

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 <janklodvan@gmail.com>:
> On Tuesday 25 November 2008 19:58:42 RB wrote:
>> KDE (and to a lesser extent X) pretty much nullifies most application
>> isolation efforts you're going to make.
>
> 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?
>
>

[gentoo-hardened] Re: hardened workstation - is that worth it?

[7v5w7go9ub0o]

Jan Klod wrote:
> Suppose, I want to take some extra precautions and set up PaX&co and MAC on a 
> workstation with Xorg and other nice KDE apps (only some of which should be 
> granted access to files in folder X). I would like to read others opinion, if 
> I can get considerable security improvements or I will have to make that much 
> of exceptions to those good rules, as it makes protection too useless?
> 
> Regards,
> Jan
> 
> 

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: [gentoo-hardened] Re: hardened workstation - is that worth it?

[Alex Efros]

Hi!

On Tue, Nov 25, 2008 at 09:02:58PM -0500, 7v5w7go9ub0o wrote:
> 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.

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. :)

-- 
			WBR, Alex.

Re: [gentoo-hardened] Re: hardened workstation - is that worth it?

[atoth]

On Sze, November 26, 2008 03:02, 7v5w7go9ub0o wrote:
> 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.

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.
-- 
dr Tóth Attila, Radiológus Szakorvos jelölt, 06-20-825-8057, 06-30-5962-962
Attila Toth MD, Radiologist in Training, +36-20-825-8057, +36-30-5962-962

Re: [gentoo-hardened] hardened workstation - is that worth it?

[Jan Klod]

On Tuesday 25 November 2008 22:14:47 RB wrote:
> On Tue, Nov 25, 2008 at 14:58, Jan Klod <janklodvan@gmail.com> wrote:
> > Actually, that sound like there is practically no way to keep networked
> > workstation really secure.
>
> 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. 
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.

> > 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)
>
> The problem, as I see it, is that you haven't defined your problem
> scope.  
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).

> 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.
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.

> 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.
Sure.

[gentoo-hardened] Re: hardened workstation - is that worth it?

[7v5w7go9ub0o]

Alex Efros wrote:
> Hi!
> 
> On Tue, Nov 25, 2008 at 09:02:58PM -0500, 7v5w7go9ub0o wrote:
>> 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.
> 
> 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! ;-)

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


> 
> 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)?

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.

> 
> 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. :)

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.

> 

[gentoo-hardened] Re: hardened workstation - is that worth it?

[7v5w7go9ub0o]

atoth-J1cgac+wqeJaB7pSnPOuKA@public.gmane.org wrote:
> On Sze, November 26, 2008 03:02, 7v5w7go9ub0o wrote:
>> 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.
> 
> 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?

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: [gentoo-hardened] hardened workstation - is that worth it?

[pageexec]

On 25 Nov 2008 at 21:36, Javier Martínez wrote:

> 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) .

- PaX flags: -------x-e-- [/usr/bin/Xorg]

and it works for me... so why do you need to disable MPROTECT on your Xorg?

Re: [gentoo-hardened] hardened workstation - is that worth it?

[Brian Kroth]

pageexec@freemail.hu <pageexec@freemail.hu> 2008-12-05 17:29:
> On 25 Nov 2008 at 21:36, Javier Martínez wrote:
> 
> > 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) .
> 
> - PaX flags: -------x-e-- [/usr/bin/Xorg]
> 
> and it works for me... so why do you need to disable MPROTECT on your Xorg?


Right.  The bottom of this page says that's no longer necessary, and it
hasn't been updated for a long time:

http://www.gentoo.org/proj/en/hardened/hardenedxorg.xml

Re: [gentoo-hardened] hardened workstation - is that worth it?

[pageexec]

On 5 Dec 2008 at 9:48, Ned Ludd wrote:

> On Fri, 2008-12-05 at 17:29 +0200, pageexec@freemail.hu wrote:
> > On 25 Nov 2008 at 21:36, Javier Martínez wrote:
> >
> > > 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) .
> >
> > - PaX flags: -------x-e-- [/usr/bin/Xorg]
> >
> > and it works for me... so why do you need to disable MPROTECT on your Xorg?
> >
>
> Could be that other ppl might start hitting that mesa bug..

if you mean the runtime generated dispatcher stubs and T&L things,
i thought they'd affect apps only, not the X server itself...

Re: [gentoo-hardened] hardened workstation - is that worth it?

[Javier Martínez]

Have you said me that I'm obsoleted?, ok, I agreed with you... o:),
but since I don't use xorg in servers... no problem. You still having
the other problems I commented. One question, somebody knows what made
xorg incompatible with pax mprotect restrictions in earlier versions?.

I put you a link that is newer than the link that Brian Kroth posted
and still having the incompatibilities on:
http://www.gentoo.org/proj/en/hardened/pax-quickstart.xml, maybe a
mistake?
2008/12/5  <pageexec@freemail.hu>:
> On 25 Nov 2008 at 21:36, Javier Martínez wrote:
>
>> 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) .
>
> - PaX flags: -------x-e-- [/usr/bin/Xorg]
>
> and it works for me... so why do you need to disable MPROTECT on your Xorg?
>
>
>

Re: [gentoo-hardened] hardened workstation - is that worth it?

[pageexec]

On 5 Dec 2008 at 18:21, Javier Martínez wrote:

> Have you said me that I'm obsoleted?, ok, I agreed with you... o:),
> but since I don't use xorg in servers... no problem. You still having
> the other problems I commented.

if you mean the /dev/mem issue, it's been solved to an extent in grsec
for a long time now as it restricts what range in that device you can
actually access - no physical memory for a start, so your trick of patching
anything in kernel memory wouldn't fly. current 2.6 series also try to offer
something like that (CONFIG_STRICT_DEVMEM) but as usual it's somewhat broken.

> One question, somebody knows what made
> xorg incompatible with pax mprotect restrictions in earlier versions?.

it was the so-called elfloader, which was the X module loader supported
and used by most distros back in the day. it handled .o files (ET_REL type
in ELF terms) and performed relocation and symbol resolution itself.

> I put you a link that is newer than the link that Brian Kroth posted
> and still having the incompatibilities on:
> http://www.gentoo.org/proj/en/hardened/pax-quickstart.xml, maybe a
> mistake?

yes, from a quick glance, many of these hardened docs could do with a
little update ;).

Re: [gentoo-hardened] hardened workstation - is that worth it?

[Javier Martínez]

One more thing, this could be understood wrongly in one earlier mail I
sent and was caused by my horrible english,
<em>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. </em>

This set the maximum capabilities that a new process could get, so,
one system restricted to CAP_SYS_RAWIO could restore the complete
Cap_bound set. You could remove for example an inmutable flag from a
binary with only CAP_SYS_RAWIO, because you could set
CAP_SYS_IMMUTABLE on in the cap_bset

2008/12/5 Javier Martínez <tazok.id0@gmail.com>:
> Have you said me that I'm obsoleted?, ok, I agreed with you... o:),
> but since I don't use xorg in servers... no problem. You still having
> the other problems I commented. One question, somebody knows what made
> xorg incompatible with pax mprotect restrictions in earlier versions?.
>
> I put you a link that is newer than the link that Brian Kroth posted
> and still having the incompatibilities on:
> http://www.gentoo.org/proj/en/hardened/pax-quickstart.xml, maybe a
> mistake?
> 2008/12/5  <pageexec@freemail.hu>:
>> On 25 Nov 2008 at 21:36, Javier Martínez wrote:
>>
>>> 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) .
>>
>> - PaX flags: -------x-e-- [/usr/bin/Xorg]
>>
>> and it works for me... so why do you need to disable MPROTECT on your Xorg?
>>
>>
>>
>

Re: [gentoo-hardened] hardened workstation - is that worth it?

[Ned Ludd]

On Fri, 2008-12-05 at 17:29 +0200, pageexec@freemail.hu wrote:
> On 25 Nov 2008 at 21:36, Javier Martínez wrote:
> 
> > 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) .
> 
> - PaX flags: -------x-e-- [/usr/bin/Xorg]
> 
> and it works for me... so why do you need to disable MPROTECT on your Xorg?
> 

Could be that other ppl might start hitting that mesa bug..