Jan Pompe wrote:
> Huge wrote:
>
>> "Stachu 'Dozzie' K." writes:
>>
>> [25 lines snipped]
>>
>>
>>> Do you really let in laptops into your internal network?
>>
>>
>>
>> How are you going to stop it?
>>
>>
> Machine gun towers.

Sorry about that.

Last place I worked at in IT some staff had desktops some had laptops so
they could take it out for demos or servicing and such things just gets
unecessarily costly to give them a laptop for the road and desktop for
the office.

Jan Pompe writes:
>Jan Pompe wrote:
>> Huge wrote:
>>
>>> "Stachu 'Dozzie' K." writes:
>>>
>>> [25 lines snipped]
>>>
>>>
>>>> Do you really let in laptops into your internal network?
>>>
>>>
>>>
>>> How are you going to stop it?
>>>
>>>
>> Machine gun towers.
>
>Sorry about that.

Not at all. made me smile.

>Last place I worked at in IT some staff had desktops some had laptops so
>they could take it out for demos or servicing and such things just gets
>unecessarily costly to give them a laptop for the road and desktop for
>the office.

It's all very well saying "no laptops", but we have 8,000 people in the building
I work in alone, and probably 20,000 Europe wide. A large number of them are
going to want laptops, plus all the visitors - every single salesman has
a laptop full of Powerpoint crap these days.

So, you can't say "no laptops". If the business want them, then the business
will have them. You have to have a policy that accommodates them.


--
"Other people are not your property."
[email me at huge [at] huge [dot] org [dot] uk]

Huge wrote:
> Jan Pompe writes:
>
>>Jan Pompe wrote:
>>
>>>Huge wrote:
>>>
>>>
>>>>"Stachu 'Dozzie' K." writes:
>>>>
>>>>[25 lines snipped]
>>>>
>>>>
>>>>
>>>>>Do you really let in laptops into your internal network?
>>>>
>>>>
>>>>
>>>>How are you going to stop it?
>>>>
>>>>
>>>
>>>Machine gun towers.
>>
>>Sorry about that.
>
>
> Not at all. made me smile.
>
>
>>Last place I worked at in IT some staff had desktops some had laptops so
>>they could take it out for demos or servicing and such things just gets
>>unecessarily costly to give them a laptop for the road and desktop for
>>the office.
>
>
> It's all very well saying "no laptops", but we have 8,000 people in the building
> I work in alone, and probably 20,000 Europe wide. A large number of them are
> going to want laptops, plus all the visitors - every single salesman has
> a laptop full of Powerpoint crap these days.

Don't car about the laptops just gimme the cool toys in their bags;-)
Where I work now the medical consultants get all the really cool stuff.

>
> So, you can't say "no laptops". If the business want them, then the business
> will have them. You have to have a policy that accommodates them.
>
>
Precisely.

On 04.12.2005, Jan Pompe wrote:
> Stachu 'Dozzie' K. wrote:
>> On 04.12.2005, Jan Pompe wrote:
>>
>>>>>>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.
>>>
>>>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.
>>
>>
>> Isn't the BIOS and boot protection obvious? It's a part of defending
>> single workstation against root privileges takeover.
>> Unless I miss something.
>
> You don't need root privileges to run 'ypcat'.

Oh really? You missed /etc/ypserv.conf configuration file.
On all my boxes using NIS you need CAP_NET_BIND_SERVICE to
`ypcat shadow'.

--
Feel free to correct my English
Stanislaw Klekot

Stachu 'Dozzie' K. wrote:
> On 04.12.2005, Jan Pompe wrote:
>
>>Stachu 'Dozzie' K. wrote:
>>
>>>On 04.12.2005, Jan Pompe wrote:
>>>
>>>
>>>>>>>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.
>>>>
>>>>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.
>>>
>>>
>>>Isn't the BIOS and boot protection obvious? It's a part of defending
>>>single workstation against root privileges takeover.
>>>Unless I miss something.
>>
>>You don't need root privileges to run 'ypcat'.
>
>
> Oh really? You missed /etc/ypserv.conf configuration file.
> On all my boxes using NIS you need CAP_NET_BIND_SERVICE to
> `ypcat shadow'.
>
True enough but it's not a problem to 'ypcat passwd' which is annoying
enough for some people.

On 04.12.2005, Jan Pompe wrote:
>>>You don't need root privileges to run 'ypcat'.
>>
>>
>> Oh really? You missed /etc/ypserv.conf configuration file.
>> On all my boxes using NIS you need CAP_NET_BIND_SERVICE to
>> `ypcat shadow'.
>>
> True enough but it's not a problem to 'ypcat passwd' which is annoying
> enough for some people.

It *could* be a problem to `ypcat passwd' *if* I wanted to. Most un*x
systems have /etc/passwd readable, so I left it possible to read the
contents of passwd.{byname,byuid}.

--
Feel free to correct my English
Stanislaw Klekot

Stachu 'Dozzie' K. wrote:
> On 04.12.2005, Jan Pompe wrote:
>
>>>>You don't need root privileges to run 'ypcat'.
>>>
>>>
>>>Oh really? You missed /etc/ypserv.conf configuration file.
>>>On all my boxes using NIS you need CAP_NET_BIND_SERVICE to
>>>`ypcat shadow'.
>>>
>>
>>True enough but it's not a problem to 'ypcat passwd' which is annoying
>>enough for some people.
>
>
> It *could* be a problem to `ypcat passwd' *if* I wanted to. Most un*x
> systems have /etc/passwd readable, so I left it possible to read the
> contents of passwd.{byname,byuid}.
>
Are you using LIDS to do this?

On 04.12.2005, Jan Pompe wrote:
> Stachu 'Dozzie' K. wrote:
>> On 04.12.2005, Jan Pompe wrote:
>>
>>>>>You don't need root privileges to run 'ypcat'.
>>>>
>>>>
>>>>Oh really? You missed /etc/ypserv.conf configuration file.
>>>>On all my boxes using NIS you need CAP_NET_BIND_SERVICE to
>>>>`ypcat shadow'.
>>>>
>>>
>>>True enough but it's not a problem to 'ypcat passwd' which is annoying
>>>enough for some people.
>>
>>
>> It *could* be a problem to `ypcat passwd' *if* I wanted to. Most un*x
>> systems have /etc/passwd readable, so I left it possible to read the
>> contents of passwd.{byname,byuid}.
>>
> Are you using LIDS to do this?

No. Just vanilla yptools 2.9 coming with Slackware 10.2 and "nis"
package (3.15) from Debian Etch. Try reading `man ypserv.conf'.

--
Feel free to correct my English
Stanislaw Klekot

Stachu 'Dozzie' K. wrote:
> On 04.12.2005, Jan Pompe wrote:
>
>>Stachu 'Dozzie' K. wrote:
>>
>>>On 04.12.2005, Jan Pompe wrote:
>>>
>>>
>>>>>>You don't need root privileges to run 'ypcat'.
>>>>>
>>>>>
>>>>>Oh really? You missed /etc/ypserv.conf configuration file.
>>>>>On all my boxes using NIS you need CAP_NET_BIND_SERVICE to
>>>>>`ypcat shadow'.
>>>>>
>>>>
>>>>True enough but it's not a problem to 'ypcat passwd' which is annoying
>>>>enough for some people.
>>>
>>>
>>>It *could* be a problem to `ypcat passwd' *if* I wanted to. Most un*x
>>>systems have /etc/passwd readable, so I left it possible to read the
>>>contents of passwd.{byname,byuid}.
>>>
>>
>>Are you using LIDS to do this?
>
>
> No. Just vanilla yptools 2.9 coming with Slackware 10.2 and "nis"
> package (3.15) from Debian Etch. Try reading `man ypserv.conf'.
>
Sorry I misspoke I was referring to setting CAP_NET_BIND_SERVICE but
since you are using vanilla yptools I guess not, but you are using
vanilla 'setpcaps'.

Still I take the warning in the man page you pointed out to me (twice
now) seriously and would not use vanilla NIS in any but a trusted
environment.

On 04.12.2005, Jan Pompe wrote:
>>>>>>>You don't need root privileges to run 'ypcat'.
>>>>>>
>>>>>>
>>>>>>Oh really? You missed /etc/ypserv.conf configuration file.
>>>>>>On all my boxes using NIS you need CAP_NET_BIND_SERVICE to
>>>>>>`ypcat shadow'.
>>>>>>
>>>>>
>>>>>True enough but it's not a problem to 'ypcat passwd' which is annoying
>>>>>enough for some people.
>>>>
>>>>
>>>>It *could* be a problem to `ypcat passwd' *if* I wanted to. Most un*x
>>>>systems have /etc/passwd readable, so I left it possible to read the
>>>>contents of passwd.{byname,byuid}.
>>>>
>>>
>>>Are you using LIDS to do this?
>>
>>
>> No. Just vanilla yptools 2.9 coming with Slackware 10.2 and "nis"
>> package (3.15) from Debian Etch. Try reading `man ypserv.conf'.
>>
> Sorry I misspoke I was referring to setting CAP_NET_BIND_SERVICE

Right. I should have guessed that.

> but
> since you are using vanilla yptools I guess not, but you are using
> vanilla 'setpcaps'.

Hnah. Capability is a bit tighter way to say what privileges are
necessary, that is what you need to have on client machine to get the
list of users with their password hashes (shadow.byname map). With no
patches

> Still I take the warning in the man page you pointed out to me (twice
> now)

Really twice? My fault, I should do it no more than once.

> seriously and would not use vanilla NIS in any but a trusted
> environment.

Is NIS over IPsec trusted enough? Aside from each host configuration (no
root users other than myself, updated system, boot fixed at C:, locked
bootloader and so on).

BTW, NIS was just a reason to learn IPsec for me. I'm going to switch to
LDAP in near future. All of that is used in computer room for students,
which is my training ground for now

--
Feel free to correct my English
Stanislaw Klekot

Stachu 'Dozzie' K. wrote:
> On 04.12.2005, Jan Pompe wrote:
>
>>>>>>>>You don't need root privileges to run 'ypcat'.
>>>>>>>
>>>>>>>
>>>>>>>Oh really? You missed /etc/ypserv.conf configuration file.
>>>>>>>On all my boxes using NIS you need CAP_NET_BIND_SERVICE to
>>>>>>>`ypcat shadow'.
>>>>>>>
>>>>>>
>>>>>>True enough but it's not a problem to 'ypcat passwd' which is annoying
>>>>>>enough for some people.
>>>>>
>>>>>
>>>>>It *could* be a problem to `ypcat passwd' *if* I wanted to. Most un*x
>>>>>systems have /etc/passwd readable, so I left it possible to read the
>>>>>contents of passwd.{byname,byuid}.
>>>>>
>>>>
>>>>Are you using LIDS to do this?
>>>
>>>
>>>No. Just vanilla yptools 2.9 coming with Slackware 10.2 and "nis"
>>>package (3.15) from Debian Etch. Try reading `man ypserv.conf'.
>>>
>>
>>Sorry I misspoke I was referring to setting CAP_NET_BIND_SERVICE
>
>
> Right. I should have guessed that.
>
>
>>but
>>since you are using vanilla yptools I guess not, but you are using
>>vanilla 'setpcaps'.
>
>
> Hnah. Capability is a bit tighter way to say what privileges are
> necessary, that is what you need to have on client machine to get the
> list of users with their password hashes (shadow.byname map). With no
> patches
>
>
>>Still I take the warning in the man page you pointed out to me (twice
>>now)
>
>
> Really twice? My fault, I should do it no more than once.
>
>
>>seriously and would not use vanilla NIS in any but a trusted
>>environment.
>
>
> Is NIS over IPsec trusted enough? Aside from each host configuration (no
> root users other than myself, updated system, boot fixed at C:, locked
> bootloader and so on).

Should be fine.
>
> BTW, NIS was just a reason to learn IPsec for me. I'm going to switch to
> LDAP in near future. All of that is used in computer room for students,
> which is my training ground for now
>

Remember there is no such thing as perfectly unbreakable lock check the
logs for the dents someone is bound to be out there looking for a bigger
hammer.

On 2005-12-04, Menno Duursma wrote:

> In providing NIS services one iplicitly trusts this to be so.

Only if you're careless. A careful implementation of NIS doesn't.

>> There're no private boxes nor root on workstations.

> How do you know this is so?

Because that's how you configure the boxes that you allow to connect to
your network.

> And has been so always?

It should be.

--

John (john@os2.dhs.org)

On Mon, 05 Dec 2005 10:23:12 +1100, Jan Pompe wrote:
> Stachu 'Dozzie' K. wrote:

>> Is NIS over IPsec trusted enough?

That depends on the exect setup of each, and how valuable the data is your
trying to protect.

>> Aside from each host configuration (no root users other than myself,
>> updated system, boot fixed at C:, locked bootloader and so on).

Agh, an other OS on the clints: yikes. Newer versions of that support
Kerberos also though (the "kdamin" differing with MIT or Shishi Kerb):
http://www.netbsd.org/Documentation/network/#win2k

> Should be fine.
>>
>> BTW, NIS was just a reason to learn IPsec for me.

Hopefully you know this already: MS-Windows 2000 lies about the encription
used, unless some package or other is installed ...

>> I'm going to switch to LDAP in near future. All of that is used in
>> computer room for students, which is my training ground for now

LDAP in and off itself is only marginally more secure then NIS. And you'd
still need maybe GSS-API (Kerberos) - say via SASL - for single-sign-on.

> Remember there is no such thing as perfectly unbreakable lock check the
> logs for the dents someone is bound to be out there looking for a bigger
> hammer.

Just a guess: they'd mess with NTP or DNS. (Hey: that rimes :-)).

--
-Menno.

On 05.12.2005, Menno Duursma wrote:
> On Mon, 05 Dec 2005 10:23:12 +1100, Jan Pompe wrote:
>> Stachu 'Dozzie' K. wrote:
>
>>> Is NIS over IPsec trusted enough?
>
> That depends on the exect setup of each, and how valuable the data is your
> trying to protect.

You're saying as if I didn't know that. Am I really making impression
that I can't think on my own?

>>> Aside from each host configuration (no root users other than myself,
>>> updated system, boot fixed at C:, locked bootloader and so on).
>
> Agh, an other OS on the clints: yikes. Newer versions of that support
> Kerberos also though (the "kdamin" differing with MIT or Shishi Kerb):
> http://www.netbsd.org/Documentation/network/#win2k

Where did I say that there is another OS? C: is a BIOS drive. That
accessible under 0x80 drive address. It's not a _partition_, it's
a _whole disk_.

>> Should be fine.
>>>
>>> BTW, NIS was just a reason to learn IPsec for me.
>
> Hopefully you know this already: MS-Windows 2000 lies about the encription
> used, unless some package or other is installed ...

Where did I say that I use IPsec under W2k on these machines? And even
further, where did I say that there is actually any Windows?

BTW. Kerberos makes sense to me when deployed on at least two different
machines. Did I say that I have more than one server to deploy something
on it?

--
Feel free to correct my English
Stanislaw Klekot

On Mon, 05 Dec 2005 19:16:39 +0000, Stachu 'Dozzie' K. wrote:
> On 05.12.2005, Menno Duursma wrote:
>> On Mon, 05 Dec 2005 10:23:12 +1100, Jan Pompe wrote:
>>> Stachu 'Dozzie' K. wrote:
>>
>>>> Is NIS over IPsec trusted enough?
>>
>> That depends on the exect setup of each, and how valuable the data is your
>> trying to protect.
>
> You're saying as if I didn't know that.

Then why ask?

> Am I really making impression that I can't think on my own?

No.

>>>> Aside from each host configuration (no root users other than myself,
>>>> updated system, boot fixed at C:, locked bootloader and so on).
>>
>> Agh, an other OS on the clints: yikes. Newer versions of that support
>> Kerberos also though (the "kdamin" differing with MIT or Shishi Kerb):
>> http://www.netbsd.org/Documentation/network/#win2k
>
> Where did I say that there is another OS? C: is a BIOS drive. That
> accessible under 0x80 drive address. It's not a _partition_, it's
> a _whole disk_.

Ah, OK thanks.

>>> Should be fine.
>>>>
>>>> BTW, NIS was just a reason to learn IPsec for me.
>>
>> Hopefully you know this already: MS-Windows 2000 lies about the encription
>> used, unless some package or other is installed ...
>
> Where did I say that I use IPsec under W2k on these machines? And even
> further, where did I say that there is actually any Windows?

I mis read that and figured C: -> MS OS ... Sorry my bad.

> BTW. Kerberos makes sense to me when deployed on at least two different
> machines.

Generally i'd say that's a good idee for NIS servers also (in availability.)

> Did I say that I have more than one server to deploy something on it?

You didn't and i don't know where i seem to have made such an assumption.
However the Shishi Kerberos implementation (althogh beta) can be
configured to run under a separate account, so that should still be an
improvement in such a setup. Provided other network servives run under
seperate acconts as well.

--
-Menno.

On 05.12.2005, Menno Duursma wrote:
> On Mon, 05 Dec 2005 19:16:39 +0000, Stachu 'Dozzie' K. wrote:
>> On 05.12.2005, Menno Duursma wrote:
>>> On Mon, 05 Dec 2005 10:23:12 +1100, Jan Pompe wrote:
>>>> Stachu 'Dozzie' K. wrote:
>>>
>>>>> Is NIS over IPsec trusted enough?
>>>
>>> That depends on the exect setup of each, and how valuable the data is your
>>> trying to protect.
>>
>> You're saying as if I didn't know that.
>
> Then why ask?

To show an example when NIS isn't that bad idea. That was a rhetorical
question. Maybe I should add tags?

>> BTW. Kerberos makes sense to me when deployed on at least two different
>> machines.
>
> Generally i'd say that's a good idee for NIS servers also (in availability.)

But Kerberos was designed to run on 2+ machines to protect other servers
(KDC, TGS and protected server(s)). Putting TGS and KDC on the same
server seems to me similar to running NIS on a single host without
network. Of course it's possible, but I'd do that mainly for testing and
learning.

[...]
> However the Shishi Kerberos implementation (althogh beta) can be
> configured to run under a separate account, so that should still be an
> improvement in such a setup. Provided other network servives run under
> seperate acconts as well.

Hmm... That's quite interesting project. Who knows, maybe I'll use this
for learning how to set up Kerberos? Thanks, anyway.

--
Feel free to correct my English
Stanislaw Klekot

On Mon, 05 Dec 2005 20:48:57 +0000, Stachu 'Dozzie' K. wrote:
> On 05.12.2005, Menno Duursma wrote:
>> On Mon, 05 Dec 2005 19:16:39 +0000, Stachu 'Dozzie' K. wrote:

>>> BTW. Kerberos makes sense to me when deployed on at least two
>>> different machines.
>>
>> Generally i'd say that's a good idee for NIS servers also (in
>> availability.)
>
> But Kerberos was designed to run on 2+ machines to protect other servers

Indeed.

> (KDC, TGS and protected server(s)).

That'd be TGS and AS. Which could be run on separate machines, but this
isn'd the "standard" setup IME.

> Putting TGS and KDC on the same server seems to me similar to running
> NIS on a single host without network.

I might not quite underatand the above centence ... If however you mean to
say services besides used/needed for autenticating shouldn't run on KDC
machines: i'd agree, exept when there isn't much choise then to do so.

> Of course it's possible, but I'd do that mainly for testing and
> learning.

Well, in what goes over the network (short lived tickets, rather net long
lived hashes) Kerberos should be saver to use then NIS for just a password
database too. Only it doesn't do identification or authorization so you'll
still need something for that (NIS will do fine for that if you can accept
the risk _that_ stuff can still be spoofed - otherwise SASL/LDAP.))

This still wouldn't protect against client admins installing keyloggers
(or using tickets - grabed from /tmp) but probably is a big improvement
over them getting a bunch (all?) of users hashes.

>> However the Shishi Kerberos implementation (althogh beta) can be
>> configured to run under a separate account, so that should still be an
>> improvement in such a setup. Provided other network servives run under
>> seperate acconts as well.
>
> Hmm... That's quite interesting project. Who knows, maybe I'll use this
> for learning how to set up Kerberos? Thanks, anyway.

Sure thing. Although i think ATM Heimdal simpler to setup, if you're
interested maybe look at (or try) the SlackBuild in this post:
http://groups.google.nl/group/alt.os...812f06c99a8174

Have fun.

--
-Menno.