[gentoo-user] Block root user from login on xorg GUI
Mick
It isn't as simple as commenting out vc7 in /etc/securetty, right? The
persistent offenders would try to start another X session on a different vc.
Is there a trick I could add in /etc/pam.d/login or one of the /etc/pam.d/gdm*
files perhaps?
--
Regards,
Mick
Paul Hartman
How do you start X? Do you use xdm/kdm/gdm or do you just "startx" or
use some other method?
Alan McKinnon
http://www.google.com/search?q=block+root+login+gdm&ie=UTF-8&oe=UTF-8
Hits #1, 2 and 3
--
alan dot mckinnon at gmail dot com
Alan McKinnon
Gdm itself has a config option to disallow root logins
Mick
> Gdm itself has a config option to disallow root logins
Ahh, unfortunately I can only access it remotely via ssh at this stage.
Hopefully the pam method will work fine.
Thanks again.
--
Regards,
Mick
Iain Buchanan
> On Thursday 12 November 2009 22:09:01 Alan McKinnon wrote:
> > Gdm itself has a config option to disallow root logins
>
> Ahh, unfortunately I can only access it remotely via ssh at this stage.
> Hopefully the pam method will work fine.
You don't need anything more to configure gdm than ssh access - this is
Linux after all & a good program has text based configurations :)
Edit /etc/X11/gdm/custom.conf
In the section [security] add:
AllowRoot=false
You may then have to restart xdm.
However, if someone has the root password to log in to X, then what's to
stop them changing anything you do now?
--
Iain Buchanan <iaindb at netspace dot net dot au>
BOFH Excuse #112:
The monitor is plugged into the serial port
Zeerak Waseem
wrote:
> However, if someone has the root password to log in to X, then what's to
> stop them changing anything you do now?
>
I've been wondering about the very same thing... Perhaps it's just to only
have a root shell and not an entire DE running as root. That's my only
(read: only useful) suggestion as to why. Because like you Iain, if
someone has the password, they could just undo the changes :-)
--
Zeerak
Paul Hartman
From what I've read, root logins are disabled by default in gdm.
Mick
> On Thu, 2009-11-12 at 22:18 +0000, Mick wrote:
> > On Thursday 12 November 2009 22:09:01 Alan McKinnon wrote:
> > > Gdm itself has a config option to disallow root logins
> >
> > Ahh, unfortunately I can only access it remotely via ssh at this stage.
> > Hopefully the pam method will work fine.
>
> You don't need anything more to configure gdm than ssh access - this is
> Linux after all & a good program has text based configurations :)
>
> Edit /etc/X11/gdm/custom.conf
>
> In the section [security] add:
> AllowRoot=false
Thanks for this! :-)
> You may then have to restart xdm.
>
> However, if someone has the root password to log in to X, then what's to
> stop them changing anything you do now?
Know how?
--
Regards,
Mick
Joshua Murphy
Approach security a little more sanely and don't give untrusted users
root access? If you have to take steps to restrict the root account,
you need to rethink who has use of it. Preventing damage in the event
that the system *does* get compromised is one thing, but trying to
control someone who is *given* access to root on the software side is
the wrong approach, in my incredibly non-humble opinion.
--
Poison [BLX]
Joshua M. Murphy
Joshua Murphy
And, a quick note on the case that the intent is to prevent the level
of damage in the event of a compromised root account, give this a
quick read over and google any terms you're not certain of the meaning
of:
Linux.com :: Securing Linux with Mandatory Access Controls
http://www.linux.com/archive/feature/113941
Nikos Chantziaras
You cannot impose any restrictions to the root user. root is
unrestricted by definition. It's useless to even start thinking about
trying. What you *can* do, is give them a VPS inside of which they are
root.
Dirk Heinrichs
> You cannot impose any restrictions to the root user. root is
> unrestricted by definition. It's useless to even start thinking about
> trying.
Ever heard about SELinux?
Bye...
Dirk
Nikos Chantziaras
Ever heard about make menuconfig?
Bye...
Alan McKinnon
Or:
Ever heard about keyboard, power switch, terminal and the ability to touch all
three?
Mick
You are right of course, but in this particular case the guy who *pays* wants
to have root access. So, I'm just trying to find an easy way to protect him
from himself. Initially I implemented SELinux, but had to pull that back
because I couldn't in any quick way get Nagios cgi working with it. One day I
may find some time to get back to it.
Alan McKinnon
> > Approach security a little more sanely and don't give untrusted users
> > root access? If you have to take steps to restrict the root account,
> > you need to rethink who has use of it. Preventing damage in the event
> > control someone who is given access to root on the software side is
> > the wrong approach, in my incredibly non-humble opinion.
>
> wants to have root access.
And you agreed to work like that?
So when he fucks things up good royal and proper, will he gladly accept his
shafting and pay you more to undo it? Or will he do the usual customer stunt
and blame you?
I only work under one of two conditions:
I am root and the customer is not.
The customer is root and I am not.
> So, I'm just trying to find an easy way to
> protect him from himself. Initially I implemented SELinux, but had to
> pull that back because I couldn't in any quick way get Nagios cgi working
> with it. One day I may find some time to get back to it.
Alan McKinnon
> Am Samstag 14 November 2009 16:13:04 schrieb Nikos Chantziaras:
> > Ever heard about make menuconfig?
>
> ???
The account foolishly being "prevented" from bypassing SELinux is root.
So, configure a new kernel, disable SELinux, build, install, reboot.
Voila! No SELinux.
Or,
Edit grub.conf, reboot.
Voila! No SELinux.
Or, (as SELinux can be used to prevent access to grub.conf)
Just hit the damn power button and edit the kernel options in the grub command
line.
Voila! No SELinux.
Lessons learned:
Trying to prevent root from doing $STUFF on a pc is utterly and completely
pointless and simply will not succeed, ever. There is hardware where this can
be done, but it's not a PC, has no Intel designs in it and is often truly
secured with armed guards.
trying to prevent root from doing $STUFF on Unix is utterly and completely
pointless and simply will not succeed, ever. There are OSes where this can be
done, but they are not Unix. By definition, on Unix root can do anything,
including bypassing systems to prevent root from doing anything.
Stroller
On 14 Nov 2009, at 20:46, Alan McKinnon wrote:
>> ...
>> You are right of course, but in this particular case the guy who pays
>> wants to have root access.
>
> And you agreed to work like that?
>
> So when he fucks things up good royal and proper, will he gladly
> accept his
> shafting and pay you more to undo it? Or will he do the usual
> customer stunt
> and blame you?
My typical experience is that the customer will take it completely on
the chin and pay me to fix the problems. That doesn't make foul-ups
due to such unnecessary meddling any less frustrating, though.
> I only work under one of two conditions:
>
> I am root and the customer is not.
> The customer is root and I am not.
This is clearly the "right" way to operate, however it can be
extremely difficult to walk away from your largest-paying contract,
just because the owner sees this particular issue differently.
One has to hope, really, that the client only wants the root password
as insurance in case you get run over by a bus, and won't use it to
arbitrarily mess about on the system.
Stroller.
Dale
I would do one thing and take it as often as possible, a large CYA
pill. I had this situation with a friend once a few years ago, trust
me, it's a lot easier to blame someone else than yourself. System logs
saved me since they pointed to him instead of me.
That pill should contain logs, notes and anything else that can be used
to protect yourself. When a scapegoat is needed, you're it. That said,
I sort of think you see this already.
Dale
:-) :-)
Dirk Heinrichs
> On Saturday 14 November 2009 22:46:18 Dirk Heinrichs wrote:
> > Am Samstag 14 November 2009 16:13:04 schrieb Nikos Chantziaras:
> > > Ever heard about make menuconfig?
> >
> > ???
>
> The account foolishly being "prevented" from bypassing SELinux is root.
>
> So, configure a new kernel, disable SELinux, build, install, reboot.
>
> Voila! No SELinux.
>
> Or,
>
> Edit grub.conf, reboot.
>
> Voila! No SELinux.
>
> Or, (as SELinux can be used to prevent access to grub.conf)
>
> Just hit the damn power button and edit the kernel options in the grub
> command line.
Compile in kernel options, configure the kernel not to accept additional ones.
Damn power button rendered useless.
> Trying to prevent root from doing $STUFF on a pc is utterly and completely
> pointless and simply will not succeed, ever. There is hardware where this
> can be done, but it's not a PC, has no Intel designs in it and is often
> truly secured with armed guards.
This all implies physical access to the machine, right?
> trying to prevent root from doing $STUFF on Unix is utterly and completely
> pointless and simply will not succeed, ever. There are OSes where this can
> be done, but they are not Unix. By definition, on Unix root can do
> anything, including bypassing systems to prevent root from doing anything.
SELinux allows to spread the tasks root needs to do or can do accross several
roles. Of course, if only one single person has root access to the system this
doesn't make sense. But we're talking about cases where several people (incl.
the malicious attacker) have root access. So you can very well configure a
(SE-)Linux system so that "root" can't do everything.
Bye...
Dirk
Alan McKinnon
> On 14 Nov 2009, at 20:46, Alan McKinnon wrote:
> >> ...
> >> You are right of course, but in this particular case the guy who pays
> >> wants to have root access.
> >
> > And you agreed to work like that?
> >
> > So when he fucks things up good royal and proper, will he gladly
> > accept his
> > shafting and pay you more to undo it? Or will he do the usual
> > customer stunt
> > and blame you?
>
> My typical experience is that the customer will take it completely on
> the chin and pay me to fix the problems. That doesn't make foul-ups
> due to such unnecessary meddling any less frustrating, though.
My experience has been completely the opposite, same with just about everyone
else I work with. But, this is a third-world country pretending to be a first-
world country, and the cowboy attitude is very prevalent here.
> One has to hope, really, that the client only wants the root password
> as insurance in case you get run over by a bus, and won't use it to
> arbitrarily mess about on the system.
I find the root password in a sealed envelope in the safe is the ideal
insurance for that.
Neil Bothwick
> > So when he fucks things up good royal and proper, will he gladly
> > accept his
> > shafting and pay you more to undo it? Or will he do the usual
> > customer stunt
> > and blame you?
>
> My typical experience is that the customer will take it completely on
> the chin and pay me to fix the problems. That doesn't make foul-ups
> due to such unnecessary meddling any less frustrating, though.
Why not use sudo to give the customer's account almost full root access?
Not only does this allow you to restrict which damaging commands he can
run but sudo logs each command it runs, so you have CYA insurance.
--
Neil Bothwick
On the other hand, you have different fingers.
Alan McKinnon
Double CYA insurance:
Send all logs to a remote syslog server. The user with sudo permissions can
still disable logging, but you have untouchable evidence that he did :-)
Stroller
On 15 Nov 2009, at 08:26, Alan McKinnon wrote:
>> ...
>> My typical experience is that the customer will take it completely on
>> the chin and pay me to fix the problems. That doesn't make foul-ups
>> due to such unnecessary meddling any less frustrating, though.
>
> My experience has been completely the opposite, same with just about
> everyone
> else I work with. But, this is a third-world country pretending to
> be a first-
> world country, and the cowboy attitude is very prevalent here.
I certainly have had some customers like that, but generally they're a
minority here. Definitely preferable is to spot them early and _follow
your instinct_ to ditch them. The longer you entertain this rubbish
the more of a headache it becomes.
>> One has to hope, really, that the client only wants the root password
>> as insurance in case you get run over by a bus, and won't use it to
>> arbitrarily mess about on the system.
>
> I find the root password in a sealed envelope in the safe is the ideal
> insurance for that.
Totally agree.
My biggest customer, unfortunately, has taken on a large investment of
capital recently, resulting in a new director who's really pretty
clueless. Basically, his dad bought him a job. He has insisted on
Domain Administrator rights because he "just wants to do the simple
stuff" himself; the first program he wanted to upgrade he needed my
help with because the installer is a piece of junk. I know that he's
going to mess things up and cost himself more money (create more
hassles for me) in the long term, but he won't hear it and I can't
just walk away; this is not only because I have a great relationship
with the other owner and also because they're currently a significant
proportion of my annual income.
He's totally a nice bloke otherwise, he just feels that I shouldn't be
"locking him out" of his own computers, and I can kinda see his point
- as an admin it's easy for me to feel "territorial" because I'm
pretty good at the job, so the chances are that anyone else isn't
going to meet my standard. Obviously it's important for me to put that
to one side.
>>> So when he fucks things up good royal and proper, will he gladly
>>> accept his shafting and pay you more to undo it? Or will he do the
>>> usualcustomer stuntand blame you?
This is actually much easier for those of us who are mere
"consultants" and who charge by the hour - we can simply reply "it was
working when i left, guv". If it's been working fine for months then
there is obviously nothing wrong with our previous work. Clearly there
is room for contention if they muck about with things right after
you've left.
Stroller.
Neil Bothwick
> > Why not use sudo to give the customer's account almost full root
> > access? Not only does this allow you to restrict which damaging
> > commands he can run but sudo logs each command it runs, so you have
> > CYA insurance.
>
> Double CYA insurance:
>
> Send all logs to a remote syslog server. The user with sudo permissions
> can still disable logging, but you have untouchable evidence that he
> did :-)
That's one approach. The other is to give sudo access only for what he
needs, which doesn't include disabling logging or many other things.
--
Neil Bothwick
Top Oxymorons Number 39: Almost exactly
Nikos Chantziaras
>
> SELinux allows to spread the tasks root needs to do or can do accross several
> roles. Of course, if only one single person has root access to the system this
> doesn't make sense. But we're talking about cases where several people (incl.
> the malicious attacker) have root access. So you can very well configure a
> (SE-)Linux system so that "root" can't do everything.
So how do you get your machine back if you forbid yourself to change its
configuration then?
Alan McKinnon
> > I find the root password in a sealed envelope in the safe is the ideal
> > insurance for that.
>
> Totally agree.
>
> My biggest customer, unfortunately, has taken on a large investment of
> capital recently, resulting in a new director who's really pretty
> clueless. Basically, his dad bought him a job. He has insisted on
> Domain Administrator rights because he "just wants to do the simple
> stuff" himself; the first program he wanted to upgrade he needed my
> help with because the installer is a piece of junk. I know that he's
> going to mess things up and cost himself more money (create more
> hassles for me) in the long term, but he won't hear it and I can't
> just walk away; this is not only because I have a great relationship
> with the other owner and also because they're currently a significant
> proportion of my annual income.
>
And you think being a "Company Director" carries any weight at all?
Tut, tut, young fellow. You have a lot to learn :-)
Tell him you will give him administrator rights if, and only if, he can
successfully solve a problem you set up. Make it something fair ( you are not
unreasonable after all).
If he fails at this, then you reduce his rights so that he can do the mundane
stuff which apparently is what he wants to be doing.
The most useful skill I ever learned in all of technology was how to tell
someone straight up and down that they don't know much, without actually
offending them.
Alan McKinnon
reboot|power down|pull power plug out|whatever and edit kernel config line to
not laod selinux