Printable View
On 2005-12-01, Jan Pompe <janp@!!dx.com.au> wrote:
[color=blue]
> Ther are a few other services which are equaaly insecure like nfs for
> instance which should aslo not run a network[/color]
Sorry, I've gotta ask...
How and why would you run nfs *NOT* on a network?
--
John (john@os2.dhs.org)
On Sat, 03 Dec 2005 00:05:10 +0000, John Thompson wrote:
[color=blue]
> AFAIK, NIS doesn't transmit passwords over the network,[/color]
It does when changeing passwords (although there are workarounds to this,
ofcource.)
[color=blue]
> just the hashes[/color]
Which i'd still consider rather risky ...
[color=blue]
> so each machine can use the hashes to authenticate.[/color]
/Only/ to autenticate users against! (Master and slave servers don't
autenticate eachother at all, nor do they clients, or clients them.)
[color=blue]
> If someone has the access to sniff these NIS exchanges[/color]
Let me guess: they'll race (or MITM) the server's replys and inject
packets to put themselfs into whatever groups they like?
[color=blue]
> to pick up the hashes,[/color]
They need not even sniff the wire for this (mitigating antisniff here.)
They'd only need administrative access to the host thier connecting to the
subnet with, and know your master and donainname ...
[color=blue]
> there's somethimg else seriously wrong with your security that isn't
> directly related to NIS,[/color]
How so?
[color=blue]
> and that person still needs to crack the hash (no trivial task) to find
> the password.[/color]
A matter of time (if there are many accounts, probably not much though.)
--
-Menno.
John Thompson wrote:
[color=blue]
> On 2005-12-01, Greg Metcalfe <metcalfegregdelete@deleteqwest.net> wrote:
>[color=green]
>> If the Network Information Service shouldn't be used on a network, where,
>> pray tell, *should* it be used? Ever worked in an environment with
>> firewalled subnets, serious security policies, etc.? Where NIS might just
>> be easy and cool, in the subnet where you need it? Where the subnet IDS
>> can spot NIS exploits like water rolling off a duck's butt? I'm guessing
>> no.[/color]
>
> AFAIK, NIS doesn't transmit passwords over the network, just the hashes so
> each machine can use the hashes to authenticate. If someone has the access
> to sniff these NIS exchanges to pick up the hashes, there's somethimg else
> seriously wrong with your security that isn't directly related to NIS, and
> that person still needs to crack the hash (no trivial task) to find the
> password.
>[/color]
I think a lot of people are probably reacting to the NIS-that-was, half a
dozen years ago. Authentication issues, buffer overflows, rogue server
attacks, etc. Modern versions are much better, as you know.
I still wouldn't deploy it on a banking transaction processor--I dumped
default NIS on such a system (not Linux) not that long ago. But that's an
environment where you clearly want to harden the system to the
hilt--billions of dollars in assets to protect. Literally. Tweak the TCP/IP
stack, rewrite /etc/skel files, etc. Pretty much the whole catastrophe, as
servers in an environment like that are probably a large proprietary Unix
server surrounded by pizza boxes running all sorts of weird stuff, and
talking to third parties. CRM interfaces, credit card processors, check
imaging services, etc.
NIS can still be an easy way to get things done, on appropriate subnets. It
all depends on the threat model. It gets my back up when people don't take
that first vital step, and issue blanket statements without actually
considering a threat model. Tons of man-hours down the tubes.
Heavy sigh, and end rant.
--
Greg Metcalfe
GPG fingerprint: 95B3 2BDD 9152 1E7D A240 37C1 7AE2 9B71 0065 F029
John Thompson wrote:
[color=blue]
> On 2005-12-01, Jan Pompe <janp@!!dx.com.au> wrote:
>[color=green]
>> Ther are a few other services which are equaaly insecure like nfs for
>> instance which should aslo not run a network[/color]
>
> Sorry, I've gotta ask...
>
> How and why would you run nfs *NOT* on a network?
>[/color]
Shades of a previous post of mine, regarding NIS not being run on a network.
And yet I dorked, and completely missed this. <wild laughter> Nice catch,
John. Though I suspect Jan just misspoke, and actually knows how useful NFS
can be, in appropriate environments.
--
Greg Metcalfe
GPG fingerprint: 95B3 2BDD 9152 1E7D A240 37C1 7AE2 9B71 0065 F029
On Fri, 02 Dec 2005 17:22:58 -0800, Greg Metcalfe wrote:[color=blue]
> John Thompson wrote:[/color]
[color=blue][color=green]
>> AFAIK, NIS doesn't transmit passwords over the network, just the hashes
>> so each machine can use the hashes to authenticate. If someone has the
>> access to sniff these NIS exchanges to pick up the hashes, there's
>> somethimg else seriously wrong with your security that isn't directly
>> related to NIS, and that person still needs to crack the hash (no
>> trivial task) to find the password.
>>[/color]
> I think a lot of people are probably reacting to the NIS-that-was, half
> a dozen years ago.[/color]
I can only speak for myself and indeed that's probably in the back of the
mind (as with say sendmail) none the less i try and look at later
revisions objectively. And even Usenet though threads tent to drift in
some direction or other, it's still about NIS security AFAICT.
[color=blue]
> Authentication issues,[/color]
To a lesser extent: still there.
[color=blue]
> buffer overflows,[/color]
Provided the OpenBSD folks audited some versions, if one uses that code,
there shouldn't be many (any) problems in that recart anymore (although it
takes just one error, and most of the NIS services runsas/needs root)
[color=blue]
> rogue server attacks, etc.[/color]
Forgive my ignorance, but how is this protected against? TCP rather then
UDP? RPC_GSS?
[color=blue]
> Modern versions are much better, as you know.[/color]
Sure. But correct me if i'm wrong: this isn't about "better" it's about
"any hole in NIS" ...
[color=blue]
> I still wouldn't deploy it on a banking transaction processor--[/color]
There you go ...
[ Snip. (Me too is a part-time server jockey for a living.) ]
[color=blue]
> NIS can still be an easy way to get things done, on appropriate subnets.[/color]
Sure. I might even _recomment_ it for home networking, small offices,
departments that share password post-ads in the first place (i.e.: users
administrate stuff themselfs), or between just info servers, for instance.
I wouldn't though recoment it for a bank, hospital, or large school, say.
[color=blue]
> It all depends on the threat model.[/color]
But is *that* what this discussion is about?
(If so, i would have / will decline(d)).
[color=blue]
> It gets my back up when people don't take that first vital step,[/color]
The OP would to have to provide data on this in the first place ... There
is no required context of user privileges , network topology , or whatever
else specified so: one is forced to conclude the security required for
his/her conclusion to be met _was_ in fact met OR his/her research skills
are lacking ...
[color=blue]
> and issue blanket statements without actually considering a threat
> model.[/color]
I don't know if you adress me with this statement, but "considering a
threat model" can only be done if one knows about the precise threats to
anything in the first place.
Weaknesses can only be accepted or mitigated if one knows about them in
the first place (one may run stunnel here or there, or switch to
SASL/Kerberos frontented LDAP, or IPSec the basterds or whatever, or not.)
[color=blue]
> Tons of man-hours down the tubes.
>
> Heavy sigh, and end rant.[/color]
--
-Menno.
matt_left_coast wrote:[color=blue]
> Jan Pompe wrote:
>
>[color=green]
>>matt_left_coast wrote:
>>[color=darkred]
>>>Jan Pompe wrote:
>>>
>>>
>>>
>>>>You are a poor logician. "It was not designed to run without a
>>>>firewall" is logically equivalent to "it was designed to run with a
>>>>firewall" it's quite irrelevent whether it was specifically done that
>>>>way or not.
>>>
>>>
>>>No, it is NOT. What you are saying does not even make sense.
>>>
>>>"Not designed" Could mean total lack of any design regarding the issue.
>>>Something could "not designed to run without a firewall" without ANY
>>>intent to design it to run WITH a firewall.
>>>
>>>Is:
>>>
>>>My car was not designed to run without a iceberg.
>>>
>>>equivalent to:
>>>
>>>My car was designed to run with a iceberg?
>>>[/color]
>>
>>That's right and both your statements are nonsense.[/color]
>
>
> I did not think you were smart enough to understand.[/color]
Probably not but I don't there are many people about who claim to
understand how a double does not make a positive as you seem to claiming
it does, so I'd be in good company at least.
[color=blue]
> Your claim that "not designed to run without a firewall" and "it was
> designed to run with a firewall" are logically the same is just plain
> BS.[/color]
(sic)[color=blue]
>[/color]
Greg Metcalfe wrote:[color=blue]
> John Thompson wrote:
>
>[color=green]
>>On 2005-12-01, Jan Pompe <janp@!!dx.com.au> wrote:
>>
>>[color=darkred]
>>>Ther are a few other services which are equaaly insecure like nfs for
>>>instance which should aslo not run a network[/color]
>>
>>Sorry, I've gotta ask...
>>
>>How and why would you run nfs *NOT* on a network?
>>[/color]
>
> Shades of a previous post of mine, regarding NIS not being run on a network.
> And yet I dorked, and completely missed this. <wild laughter> Nice catch,
> John. Though I suspect Jan just misspoke,[/color]
You may be right, I really should brush up my irony/sarcasm skills it's
obviously not working as well as I'd like.
[color=blue]
> and actually knows how useful NFS
> can be, in appropriate environments.
>[/color]
Indeed I do though I have no used for it at present I have used it in
the past behind a solid and layered firewall. Never had any problems,
but then I never had to administer a network in a school where there be
students who might think it clever to break it.
John Thompson <john@vector.os2.dhs.org> writes:
[color=blue]
>AFAIK, NIS doesn't transmit passwords over the network, just the hashes so
>each machine can use the hashes to authenticate. If someone has the access
>to sniff these NIS exchanges to pick up the hashes, there's somethimg else
>seriously wrong with your security that isn't directly related to NIS,[/color]
You mean, like they've plugged a laptop into your network and used arp cache
poisoning to get the switch to go into broadcast mode.
But they don't need to be that clever. There's no authentication on NIS. Anyone
on the network can download your password hashes.
[color=blue]
> and
>that person still needs to crack the hash (no trivial task)[/color]
*ONLY* if you ruthlessly enforce strong password discipline. I've never been
anywhere where it happens.
--
"Other people are not your property."
[email me at huge [at] huge [dot] org [dot] uk]
On 2005-12-03, Menno Duursma <menno@desktop.lan> wrote:
[color=blue]
> On Sat, 03 Dec 2005 00:05:10 +0000, John Thompson wrote:
>[color=green]
>> If someone has the access to sniff these NIS exchanges
>> to pick up the hashes,[/color][/color]
[color=blue]
> They need not even sniff the wire for this (mitigating antisniff here.)
> They'd only need administrative access to the host thier connecting to the
> subnet with, and know your master and donainname ...[/color]
Seems to me if they have administrator access, they can pretty much do
what they want already, without having to go through the bother of
sniffing nfs packets.
[color=blue][color=green]
>> there's something else seriously wrong with your security that isn't
>> directly related to NIS,[/color][/color]
[color=blue]
> How so?[/color]
See above.
--
John (john@os2.dhs.org)
Jan Pompe wrote:[color=blue]
> matt_left_coast wrote:
>[color=green]
>> Jan Pompe wrote:[/color][/color]
[...] snip
[color=blue]
>
> That's right and both your statements are nonsense.
>[/color]
Jan, in case it hasn't occured to you by now, binky-boy Matt doesn't
have all of his oars in the water.
On Sat, 03 Dec 2005 22:05:08 +0000, John Thompson wrote:[color=blue]
> On 2005-12-03, Menno Duursma <menno@desktop.lan> wrote:[color=green]
>> On Sat, 03 Dec 2005 00:05:10 +0000, John Thompson wrote:
>>[color=darkred]
>>> If someone has the access to sniff these NIS exchanges
>>> to pick up the hashes,[/color][/color]
>[color=green]
>> They need not even sniff the wire for this (mitigating antisniff here.)[/color][/color]
man ypcat
[color=blue][color=green]
>> They'd only need administrative access to the host thier connecting to
>> the subnet with, and know your master and donainname ...[/color][/color]
s/donainname/domainname/
[color=blue]
> Seems to me if they have administrator access, they can pretty much do
> what they want already,[/color]
Locally, on the machine (laptop?) thier connecting with: yes. That's fully
under thier control already. Access to server resources however they
_shouldn't_ have at thier disposal without authenticating (unless it's a
public service anyway.)
[color=blue]
> without having to go through the bother of sniffing nfs packets.
>[color=green][color=darkred]
>>> there's something else seriously wrong with your security that isn't
>>> directly related to NIS,[/color][/color]
>[color=green]
>> How so?[/color]
>
> See above.[/color]
Well, between servers (that provide autenticated services) where you have
only non-root users on: there isn't a problem with using NIS (and plain
ol' NFS for that matter.) In which case any and all machines connected to
that network segment are trusted to behave (e.g.: *not* provide root to
untrusted users.)
But if this cannot be guaranteed (i.e.: there are workstations on) NIS
cannot be used without accepting a relatively big risk in so doing.
--
-Menno.
On 03.12.2005, Menno Duursma <menno@desktop.lan> wrote:[color=blue]
> On Sat, 03 Dec 2005 22:05:08 +0000, John Thompson wrote:[color=green]
>> On 2005-12-03, Menno Duursma <menno@desktop.lan> wrote:[color=darkred]
>>> On Sat, 03 Dec 2005 00:05:10 +0000, John Thompson wrote:
>>>
>>>> If someone has the access to sniff these NIS exchanges
>>>> to pick up the hashes,[/color]
>>[color=darkred]
>>> They need not even sniff the wire for this (mitigating antisniff here.)[/color][/color]
>
> man ypcat
>[color=green][color=darkred]
>>> They'd only need administrative access to the host thier connecting to
>>> the subnet with, and know your master and donainname ...[/color][/color]
>
> s/donainname/domainname/
>[color=green]
>> Seems to me if they have administrator access, they can pretty much do
>> what they want already,[/color]
>
> Locally, on the machine (laptop?) thier connecting with: yes. That's fully
> under thier control already. Access to server resources however they
> _shouldn't_ have at thier disposal without authenticating (unless it's a
> public service anyway.)[/color]
Do you really let in laptops into your internal network? Or maybe you
connect with bridge/switch wireless network with stationary network?
This _is_ serious design flaw. So now we now that you don't let laptops
in. Which other systems can "they" posses? Your desktop systems? Then
you failed as system admin.
Where is root access to systems in internal network _now_?
[color=blue][color=green]
>> without having to go through the bother of sniffing nfs packets.
>>[color=darkred]
>>>> there's something else seriously wrong with your security that isn't
>>>> directly related to NIS,[/color]
>>[color=darkred]
>>> How so?[/color]
>>
>> See above.[/color]
>
> Well, between servers (that provide autenticated services) where you have
> only non-root users on: there isn't a problem with using NIS (and plain
> ol' NFS for that matter.) In which case any and all machines connected to
> that network segment are trusted to behave (e.g.: *not* provide root to
> untrusted users.)
>
> But if this cannot be guaranteed (i.e.: there are workstations on) NIS
> cannot be used without accepting a relatively big risk in so doing.[/color]
Do you give to workstation user root access to that workstation? I don't
think so. Can you explain then, how your user could get administrative
rights? There're no private boxes nor root on workstations.
--
Feel free to correct my English
Stanislaw Klekot
base60 wrote:[color=blue]
> Jan Pompe wrote:
>[color=green]
>> matt_left_coast wrote:
>>[color=darkred]
>>> Jan Pompe wrote:[/color][/color]
>
>
> [...] snip
>[color=green]
>>
>> That's right and both your statements are nonsense.
>>[/color]
>
> Jan, in case it hasn't occured to you by now, binky-boy Matt doesn't
> have all of his oars in the water.[/color]
I can be a bit slow about such things but it was begining to dawn on me.
I left IT sometime ago to work in rehabilitating people with
shizophrenia + drug abuse problems and given that environment he seems
almost high functioning.
Thanks.
On Sun, 04 Dec 2005 00:54:03 +0000, Stachu 'Dozzie' K. wrote:[color=blue]
> On 03.12.2005, Menno Duursma <menno@desktop.lan> wrote:[color=green]
>> On Sat, 03 Dec 2005 22:05:08 +0000, John Thompson wrote:[/color][/color]
[color=blue]
> Do you really let in laptops into your internal network?[/color]
Well the only network i own is my home LAN and yes i have a laptop.
[color=blue]
> Or maybe you connect with bridge/switch wireless network with stationary
> network?[/color]
Wouldn't this effectively make it /one/ network above the media level?
[color=blue]
> This _is_ serious design flaw.[/color]
???
[color=blue]
> So now we now that you don't let laptops in.[/color]
On other networks then mensioned above: i have no say in such things,
above and beyond consultancy. But assume it possible and in most places
not even far fetched ...
[color=blue]
> Which other systems can "they" posses? Your desktop systems?[/color]
Probably: given some effort. But they need not even try that (just
crosslink a laptop to one desktop systems NIC, fail a login on it
logging results on the laptop, spoof thier settings to those and connect
it to the network - and this is when they'd even care for going undetected.)
[ Snip. ]
[color=blue]
> Do you give to workstation user root access to that workstation?[/color]
What's with all the personal questions? Thier irrelevant to the discussion
as far as i'm concerned.
[color=blue]
> I don't think so.[/color]
In providing NIS services one iplicitly trusts this to be so. Other
systems, providing similar functionality, take into account the
alternative possibility could conceivably be the case, if only for a small
timeframe. Protecting assets even from legit users with local root access
on client machines (say tech support admins.)
[color=blue]
> Can you explain then, how your user could get administrative rights?[/color]
Read above (ofcource there are more ways to skim a cat, use your
imagination.) You can tunnel/wrap/firewall/whatever sure, that's not my
point. Point though is: NIS doesn't savely account for the possibility...
[color=blue]
> There're no private boxes nor root on workstations.[/color]
How do you know this is so?
And has been so always?
--
-Menno.
On 04.12.2005, Menno Duursma <menno@desktop.lan> wrote:[color=blue]
> On Sun, 04 Dec 2005 00:54:03 +0000, Stachu 'Dozzie' K. wrote:[color=green]
>> On 03.12.2005, Menno Duursma <menno@desktop.lan> wrote:[color=darkred]
>>> On Sat, 03 Dec 2005 22:05:08 +0000, John Thompson wrote:[/color][/color]
>[color=green]
>> Do you really let in laptops into your internal network?[/color]
>
> Well the only network i own is my home LAN and yes i have a laptop.
>[color=green]
>> Or maybe you connect with bridge/switch wireless network with stationary
>> network?[/color]
>
> Wouldn't this effectively make it /one/ network above the media level?
>[color=green]
>> This _is_ serious design flaw.[/color]
>
> ???[/color]
We're talking about networks where NIS can do some work, that is
networks requiring some directory services, aren't we? Otherwise NIS is
unnecessary service and leaving it running is exactly the same "good"
idea as leaving Samba, Apache or any other useless service (providing
it's useless in particular case).
[color=blue][color=green]
>> So now we now that you don't let laptops in.[/color]
>
> On other networks then mensioned above: i have no say in such things,
> above and beyond consultancy. But assume it possible and in most places
> not even far fetched ...
>[color=green]
>> Which other systems can "they" posses? Your desktop systems?[/color]
>
> Probably: given some effort.[/color]
Then the system admin failed.
[color=blue]
> But they need not even try that (just
> crosslink a laptop to one desktop systems NIC, fail a login on it
> logging results on the laptop, spoof thier settings to those and connect
> it to the network - and this is when they'd even care for going undetected.)[/color]
As I said, there're no laptops. Laptops are left at the entrance.
Netadmin should provide clear and forcable policy.
[color=blue][color=green]
>> Do you give to workstation user root access to that workstation?[/color]
>
> What's with all the personal questions? Thier irrelevant to the discussion
> as far as i'm concerned.[/color]
Right. I've taken you on my sight just because it's easier to me to form
a sentence (at the language level; I don't speak English natively).
Nothing personal. I apologize if you feel offended.
[color=blue][color=green]
>> I don't think so.[/color]
>
> In providing NIS services one iplicitly trusts this to be so. Other
> systems, providing similar functionality, take into account the
> alternative possibility could conceivably be the case, if only for a small
> timeframe. Protecting assets even from legit users with local root access
> on client machines (say tech support admins.)[/color]
Serving root through any directory service isn't too smart, I think.
One might try to intercept messages exchanged in authentication
procedure and crack root password offline. I can hardly imagine the
situation _requiring_ serving root account through DS.
[color=blue][color=green]
>> Can you explain then, how your user could get administrative rights?[/color]
>
> Read above (ofcource there are more ways to skim a cat, use your
> imagination.) You can tunnel/wrap/firewall/whatever sure, that's not my
> point. Point though is: NIS doesn't savely account for the possibility...[/color]
Of course it doesn't. It wasn't designed to address these possibilities
(NIS+ reportedly was, but there's no NIS+ servers for Linux out there).
It's just its property. But it is not a security flaw itself. The flaw
is not to take this NIS property into an account. I suppose both of us
can agree with that.
--
Feel free to correct my English
Stanislaw Klekot
Jan Pompe wrote:[color=blue]
> base60 wrote:
>[color=green]
>> Jan Pompe wrote:
>>[color=darkred]
>>> matt_left_coast wrote:
>>>
>>>> Jan Pompe wrote:[/color]
>>
>>
>>
>> [...] snip
>>[color=darkred]
>>>
>>> That's right and both your statements are nonsense.
>>>[/color]
>>
>> Jan, in case it hasn't occured to you by now, binky-boy Matt doesn't
>> have all of his oars in the water.[/color]
>
>
> I can be a bit slow about such things but it was begining to dawn on me.
>
> I left IT sometime ago to work in rehabilitating people with
> shizophrenia + drug abuse problems and given that environment he seems
> almost high functioning.[/color]
From that perspective, think coke-head syndrome.
Couldn't do that job... you're a better man than I, Gunga Din.
Stachu 'Dozzie' K. wrote:[color=blue]
> On 04.12.2005, Menno Duursma <menno@desktop.lan> wrote:
>[color=green]
>>On Sun, 04 Dec 2005 00:54:03 +0000, Stachu 'Dozzie' K. wrote:
>>[color=darkred]
>>>On 03.12.2005, Menno Duursma <menno@desktop.lan> wrote:
>>>
>>>>On Sat, 03 Dec 2005 22:05:08 +0000, John Thompson wrote:[/color]
>>[color=darkred]
>>>Do you really let in laptops into your internal network?[/color]
>>
>>Well the only network i own is my home LAN and yes i have a laptop.
>>
>>[color=darkred]
>>>Or maybe you connect with bridge/switch wireless network with stationary
>>>network?[/color]
>>
>>Wouldn't this effectively make it /one/ network above the media level?
>>
>>[color=darkred]
>>>This _is_ serious design flaw.[/color]
>>
>>???[/color]
>
>
> We're talking about networks where NIS can do some work, that is
> networks requiring some directory services, aren't we? Otherwise NIS is
> unnecessary service and leaving it running is exactly the same "good"
> idea as leaving Samba, Apache or any other useless service (providing
> it's useless in particular case).
>
>[color=green][color=darkred]
>>>So now we now that you don't let laptops in.[/color]
>>
>>On other networks then mensioned above: i have no say in such things,
>>above and beyond consultancy. But assume it possible and in most places
>>not even far fetched ...
>>
>>[color=darkred]
>>>Which other systems can "they" posses? Your desktop systems?[/color]
>>
>>Probably: given some effort.[/color]
>
>
> Then the system admin failed.
>
>[color=green]
>>But they need not even try that (just
>>crosslink a laptop to one desktop systems NIC, fail a login on it
>>logging results on the laptop, spoof thier settings to those and connect
>>it to the network - and this is when they'd even care for going undetected.)[/color]
>
>
> As I said, there're no laptops. Laptops are left at the entrance.
> Netadmin should provide clear and forcable policy.[/color]
I for one can't see how this will make a significant difference given
access to desktops on the network. Memory sticks and floppy disks quite
concealable. If you are administering a network where you have users you
can't trust you need added layers of protection or alternative setups.
[color=blue]
>
>[color=green][color=darkred]
>>>Do you give to workstation user root access to that workstation?[/color]
>>
>>What's with all the personal questions? Thier irrelevant to the discussion
>>as far as i'm concerned.[/color]
>
>
> Right. I've taken you on my sight just because it's easier to me to form
> a sentence (at the language level; I don't speak English natively).[/color]
Neither does Menno. It's not my native language either. I didn't see the
questions as particularly personal though just a way of asking opinion.
[color=blue]
> Nothing personal. I apologize if you feel offended.
>
>[color=green][color=darkred]
>>>I don't think so.[/color]
>>
>>In providing NIS services one iplicitly trusts this to be so. Other
>>systems, providing similar functionality, take into account the
>>alternative possibility could conceivably be the case, if only for a small
>>timeframe. Protecting assets even from legit users with local root access
>>on client machines (say tech support admins.)[/color]
>
>
> Serving root through any directory service isn't too smart, I think.
> One might try to intercept messages exchanged in authentication
> procedure and crack root password offline. I can hardly imagine the
> situation _requiring_ serving root account through DS.
>
>[color=green][color=darkred]
>>>Can you explain then, how your user could get administrative rights?[/color]
>>
>>Read above (ofcource there are more ways to skim a cat, use your
>>imagination.) You can tunnel/wrap/firewall/whatever sure, that's not my
>>point. Point though is: NIS doesn't savely account for the possibility...[/color]
>
>
> Of course it doesn't. It wasn't designed to address these possibilities
> (NIS+ reportedly was, but there's no NIS+ servers for Linux out there).
> It's just its property. But it is not a security flaw itself. The flaw
> is not to take this NIS property into an account. I suppose both of us
> can agree with that.
>[/color]
On 04.12.2005, Jan Pompe <janp@!!dx.com.au> wrote:[color=blue][color=green][color=darkred]
>>>>Which other systems can "they" posses? Your desktop systems?
>>>
>>>Probably: given some effort.[/color]
>>
>>
>> Then the system admin failed.
>>
>>[color=darkred]
>>>But they need not even try that (just
>>>crosslink a laptop to one desktop systems NIC, fail a login on it
>>>logging results on the laptop, spoof thier settings to those and connect
>>>it to the network - and this is when they'd even care for going undetected.)[/color]
>>
>>
>> As I said, there're no laptops. Laptops are left at the entrance.
>> Netadmin should provide clear and forcable policy.[/color]
>
> I for one can't see how this will make a significant difference given
> access to desktops on the network. Memory sticks and floppy disks quite
> concealable. If you are administering a network where you have users you
> can't trust you need added layers of protection or alternative setups.[/color]
Isn't the BIOS and boot protection obvious? It's a part of defending
single workstation against root privileges takeover.
Unless I miss something. (Protection against bringing SUIDed binaries is
just another obviousness, so don't count it.)
--
Feel free to correct my English
Stanislaw Klekot
Stachu 'Dozzie' K. wrote:[color=blue]
> On 04.12.2005, Jan Pompe <janp@!!dx.com.au> wrote:
>[color=green][color=darkred]
>>>>>Which other systems can "they" posses? Your desktop systems?
>>>>
>>>>Probably: given some effort.
>>>
>>>
>>>Then the system admin failed.
>>>
>>>
>>>
>>>>But they need not even try that (just
>>>>crosslink a laptop to one desktop systems NIC, fail a login on it
>>>>logging results on the laptop, spoof thier settings to those and connect
>>>>it to the network - and this is when they'd even care for going undetected.)
>>>
>>>
>>>As I said, there're no laptops. Laptops are left at the entrance.
>>>Netadmin should provide clear and forcable policy.[/color]
>>
>>I for one can't see how this will make a significant difference given
>>access to desktops on the network. Memory sticks and floppy disks quite
>>concealable. If you are administering a network where you have users you
>>can't trust you need added layers of protection or alternative setups.[/color]
>
>
> Isn't the BIOS and boot protection obvious? It's a part of defending
> single workstation against root privileges takeover.
> Unless I miss something.[/color]
You don't need root privileges to run 'ypcat'.
[color=blue]
> (Protection against bringing SUIDed binaries is
> just another obviousness, so don't count it.)[/color]
This NFS does protect against by changing ownership of root owned files
to nfsnobody (or something like that - it's been a while since I've used
anything like that).
Point is of course one should tailor the network to optimise utility and
security
and try to achieve a balance between minimising the risks and optimising
utility (production).
If you are in a situation where you feel it's necessary to ban laptops I
might even suggest that you look for alternative solutions to raw NIS & NFS.
"Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> writes:
[25 lines snipped]
[color=blue]
>Do you really let in laptops into your internal network?[/color]
How are you going to stop it?
--
"Other people are not your property."
[email me at huge [at] huge [dot] org [dot] uk]