Mailing List Archive

1 2  View All
Re: Re: Disable SPP On GCC-4.8.3 [ In reply to ]
On Tue, Jun 17, 2014 at 6:44 PM, Barry Schwartz
<chemoelectric@chemoelectric.org> wrote:
> Mark Knecht <markknecht@gmail.com> skribis:
>> As this topic is on-going, let my ask about -fno-stack-protector. I
>> haven't messed with my build flags in literally years, and certainly
>> not since I built this machine in 2010 where I only use CFLAGS="-O2
>> -march=native -pipe" . WRT to -fno-stack-protector does enabling a
>> flag like that in make.conf then trigger a requirement to rebuild
>> everything (emerge -e @world) or can one turn it on and just update
>> the machine package-by-package over time?
>
> If you _do not_ enable -fno-stack-protector you will get packages
> updated over time, once you start using 4.8.3+ as your system
> compiler. Enabling -fno-stack-protector is the way to keep things the
> same.
>
Thanks for the clarifications Barry.
Cheers,
Mark
Re: Disable SPP On GCC-4.8.3 [ In reply to ]
Frank Peters posted on Tue, 17 Jun 2014 09:04:34 -0400 as excerpted:

> The problem with all Linux distributions, and not just Gentoo, is that
> they are directed toward a multi-user, networked environment. As a
> consequence, they exhibit security and other features that generally
> make no sense whatsoever for a single-user desktop machine that
> optionally connects externally only with an ISP through a router/modem.

> In the single-user, desktop environment, the probability of a buffer
> overflow "attack" is virtually nil, especially if one is highly
> selective about "surfing" the Internet and employing Internet software
> (which I am).

> My system is configured in a way that is quite contrary to recommended
> Linux practice (for example I run only and always as the root superuser
> and have no need for file permissions) but yet it makes perfect sense
> for my situation.
>
> Are single desktop users that much of a minority? I would hope not.

While I strongly disagree with your position, I equally strongly respect
you for knowing what you want and sticking to it. As I said earlier,
gentoo wouldn't be gentoo if it didn't both allow such a thing and make
it reasonably easy by exposing and automating the tools necessary to do
such things, and that sort of individualism is /exactly/ what gentoo is
about. =:^)

As to the disagreement, I guess I'm a single-human-user desktop system
user too. But I recognize the benefits of running various daemons as
their own (non-human) user, for instance, and in fact, I've gone to some
lengths to setup two entirely separate user accounts, a generic user
account and a sysadmin account, so I don't have to "take the name of root
in vain" when I have my sysadmin hat on.

My normal user is deliberately quite restricted, only a very few
restricted sudo commands available, etc. It's the only one that runs X.
One of the few things that user CAN do, however, is sudo (with password)
to the admin user.

The admin user in turn has unrestricted passwordless sudo, but does NOT
operate as root /without/ that sudo. Running as the admin user, among
other things I avoid live-editing a potentially damaging command (like
rming a system file) as root -- I type the command in and initially run
it as the unprivileged admin user. Of course then the risky command
fails with a permissions error, but in so doing it lets me see exactly
what it WOULD have done (which files it would rm, etc). If and only if
it's the file(s) that I intended (and ONLY those files), I can quickly
uparrow to bring the command back, hit home and add the sudo, to run the
command for real. But that admin user doesn't run X, nor can I su or sudo
any X-based apps as root, from my normal X-using user. Superuser is
strictly limited to the commandline, and even then, I normally don't run
a full shell as superuser, instead only executing specific commands as
superuser using sudo.

So quite in contrast to you, I don't normally even escalate to superuser
even when I'm doing admin tasks, except for specific commands. But sudo
and sudoedit (which I have aliased to simply s and se, respectively, with
an smc for sudo mc, as another frequently used alias) are tools I use all
the time.

Meanwhile, as rich0 already alluded to, several of the recent malware
incidents have been propagated via otherwise legitimate ad-networks,
placing vuln-trigger ads on otherwise legitimate and widely respected web
sites. If you're running ads on your favorite news site, you're
potentially vulnerable, as that's specifically the channel of attack
they're using these days.

Now of course I run noscript and request-policy, both set to whitelist
mode, blacklisting all off-site scripts and all site-to-site-connections
except those that I've specifically allowed, and I also run privoxy, so I
don't tend to see many ads. And I don't actually have any plugins
registered either and DEFINITELY no servantware such as flash, another
typical malware-injection method.

But that doesn't mean I don't appreciate stack-smashing protection and
the like for my browser, and in fact, every time /any/ program segfaults
or the like, I find myself quickly evaluating the chance that said
segfault was due to a buffer overflow, what might have triggered it, the
data I was working on at the time and where it came from, and the
potential risk of malware injection. So I'm certainly appreciating this
SSP here as I appreciate the lowering of risk profile it brings! =:^)

But obviously your use-case and mine are about as contrasted as they
could be even if we're both running single-human-user desktop systems;
you're running as root all the time, while I try not to even run a shell
as root. You don't care about SSP and the like, while I definitely
appreciate the lower risk profile and spend a significant amount of my
time educating myself on current security issues and actively avoiding
things that might increase my risk profile.

But as I said, I can and do still respect that. You have every right to
run that way if you like, and gentoo even tends to make it easier for you
to do so. =:^)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
Re: Re: Disable SPP On GCC-4.8.3 [ In reply to ]
On Wed, 18 Jun 2014 03:31:30 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

>
> While I strongly disagree with your position, I equally strongly respect
> you for knowing what you want and sticking to it ...
>
> As to the disagreement, I guess I'm a single-human-user desktop system
> user too. But I recognize the benefits of running various daemons as
> their own (non-human) user ...
>
> So quite in contrast to you, I don't normally even escalate to superuser
> even when I'm doing admin tasks ...
>

It's amazing how people become nearly apoplectic whenever they encounter
a case of a user running entirely as root.

For me it's no big deal. I've been doing it happily, and without problem,
since since 1997 (when I first discovered Linux). It also un-complicates
things greatly.

For me there is only one user, and that's the guy who owns and operates
the machine (root). What could be simpler?

But I've learned not to discuss such behavior with others. They will
always react in alarmist ways.

I won't even mention that, until recently, I used to boot my machine
directly into a bash shell, skipping all that SysV (or other) initialization
nonsense. Fortunately, the Linux kernel allows one to do just that.
It always has and hopefully always will. Booting into bash is very
simple. All that is required is to define some environmental variables
in the bashrc and one is good to go. All other configuration can
be done as needed (or if needed). This is Linux at its very best, IMO.

But, as I already indicated, these things cannot be freely discussed.
People will react strongly and begin to adduce all sorts of reasons
why such behavior is dangerous. So, for me, it is always a case of don't
talk and don't listen.

Frank Peters
Re: Re: Disable SPP On GCC-4.8.3 [ In reply to ]
On Wed, 18 Jun 2014 00:06:35 -0500
Barry Schwartz <chemoelectric@chemoelectric.org> wrote:

> Frank Peters <frank.peters@comcast.net> skribis:
> It's amazing how people become nearly apoplectic whenever they encounter
> a case of a user running entirely as root.

>
> It’s no worse than running MSDOS, and it’s
> typical practice when running from, for instance, a rescue disk. The
> main risk is accidentally deleting or overwriting things, not
> break-ins.
>

You can completely eliminate accidental deletions or overwrites
as root by using the extended file attributes. For example, on
an ext2/3/4 file system, the command "chattr +i files..." will
prevent all modifications, links, deletions, or overwrites to the
selected files. The "i" attribute is the "immutable" attribute
and is very nice to have.

To delete such files just clear the "i" bit. (I have set up
a script in Midnight Commander where I can render files
immutable or mutable with a quick keystroke.)

Frank Peters
Re: Re: Disable SPP On GCC-4.8.3 [ In reply to ]
Frank Peters <frank.peters@comcast.net> skribis:
> You can completely eliminate accidental deletions or overwrites
> as root by using the extended file attributes. For example, on
> an ext2/3/4 file system, the command "chattr +i files..." will
> prevent all modifications, links, deletions, or overwrites to the
> selected files. The "i" attribute is the "immutable" attribute
> and is very nice to have.

Sure. And I have extended file attributes turned on all over the
place, because I use the draft Posix ACLs in spots. Particularly for
the local repos of my Gentoo overlays.
Re: Disable SPP On GCC-4.8.3 [ In reply to ]
Frank Peters posted on Wed, 18 Jun 2014 00:45:35 -0400 as excerpted:

> I won't even mention that, until recently, I used to boot my machine
> directly into a bash shell, skipping all that SysV (or other)
> initialization nonsense. Fortunately, the Linux kernel allows one to do
> just that.
> It always has and hopefully always will. Booting into bash is very
> simple. All that is required is to define some environmental variables
> in the bashrc and one is good to go. All other configuration can be
> done as needed (or if needed). This is Linux at its very best, IMO.

Now that I can definitely agree with. I actually have a grub (grub2)
option that adds init=/bin/bash to the kernel commandline, so I don't
have to add it manually (at the grub CLI), and depend on it continuing to
work as an emergency maintenance tool.

It works rather well, actually. And I believe it's relatively common in
the embedded world to boot directly to a dedicated shell script as init,
particularly if they've only a few special purpose commands to run. In
that case it's a lot simpler and easier to maintain than a full "proper"
init-system, and generally rather smaller, as well.

And FWIW I've seen people do single-purpose LiveISOs that boot directly
into a game or movie player or whatever, too. Certainly to one coming
from the MS world it can seem really quite amazing how flexible Linux is
in this regard.

Meanwhile, many initr* setups do pretty much exactly that as well,
booting to a big shell script that runs udev and otherwise sets up the
initr* emergency platform in case the main root doesn't mount, before
mounting the main root and doing a pivot-root into it as it hands off to
the main root init.

And booting direct to a bash shell prompt as init makes a lot of sense in
other cases where the needed setup is simple enough that a "proper" init
doesn't make sense, too.

While my main system here is running enough daemons and etc, plus I
actually make use of systemd's ability to babysit and restart services,
that replacing it all with a big shell script would be brittle and
complex to maintain in comparison to actually using an init system
properly designed for that purpose, IIRC my router (running openwrt, tho
it's an old installation that I need to update one of these days)
actually boots to a shell script as init, and it really does make a lot
of sense at that level.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

1 2  View All