Jakub 'Livio' Rusinek wrote:

On 26.03.2009 07:15, Rajko M. wrote:

...

Just example what new users hit when they try Linux: http://blogs.computerworld.com/a_newbie_turns_to_linux

Samba is notorious problem.

This is not the only problem. It's very hard to investigate why it doesn't work and how to configure it.

I can tell you from my own experience, that the only situation when I had Samba-Windows networking working, is when computers were connected directly by cable with static IPs.

Dynamic IPs and Samba stops working. It's even worse when you get a router or other device...

Uh, I've been running samba in such an environment for 3-4 years, never had any problems with it. /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Il giorno gio, 26/03/2009 alle 17.04 +0100, Per Jessen ha scritto:

Rajko, how do you determine when something "should" be installed?

Maybe YaST should attempt to determine if an installation is happening in a Windows-"environment" and auto-select samba?

Maybe he was talking about installing samba server by default together with its YaST module, instead than only the client? Just guessing. Regards, A. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Thursday 26 March 2009 12:23:37 pm jdd wrote:

Alberto Passalacqua a écrit :

...

Maybe he was talking about installing samba server by default together with its YaST module, instead than only the client? Just guessing.

what about installing all the yast modules? they are small and it's not always obvious to know there is a module :-) (specially when they are new)

One additional menu entry in YaST Control Center with all modules that are not installed would not hurt, but doing that is possible only if: - someone knows how to do that, - has time to do that, or learn few languages that can be used to write YaST modules, and find time to create addition. With one click install, the barrier to do that in other way is lowered to level of basic html editing. One has to write html document with collection of 1-click links. To make it more attractive links can be equipped with nice graphics, the same of the kind css, and accessed trough web browser. All that is needed is improvement in YaST Metapackage Handler, not to add existing repositories, and to do basic check, is package already installed, before anything else. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Saturday 28 March 2009 08:31:06 am Benji Weber wrote:

2009/3/28 Rajko M. :

...

All that is needed is improvement in YaST Metapackage Handler, not to add existing repositories, and to do basic check, is package already installed, before anything else.

Unfortunately there's not actually a way to identify whether two repositories are the same. It already compares the URIs and the names/aliases, but the same repository can have different values for all of these.

Like simlink from current to 11.1, for instance ? -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Ivan N. Zlatev wrote:

Yes this is indeed ridiculous. Samba / Windows Shares browsing doesn't *NOT* work out of the box on openSUSE. The reason is that it's blocked in the Firewall by default.

Presumably Samba runs on a private network, which the firewall is intended to protect from the public network. Sounds like a Firewall configuration issue most of all.

FAIL FAIL FAIL FAIL FAIL FAIL FAIL FAIL FAIL FAIL.

I don't if it's really that bad, but how about writing a bugreport and getting it fixed.

I keep thinking there are 1) too little developers working on openSUSE 2) too little users

I think we should be thankful that we have developers instead users developing openSUSE :-) But it would undoubtedly be nice with more users testing, such that issues such as this could have been reported.

3) too many things that are broken out of the box on openSUSE (e.g 11.1 disk burning was broken., the release before the package manager was broken)

I don't recognize that at all, but maybe I need the right set of end-users glasses to see through. /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Il giorno gio, 26/03/2009 alle 19.33 +0100, Per Jessen ha scritto:

I don't if it's really that bad, but how about writing a bugreport and getting it fixed.

It has been done regularly at each release cycle, starting from 10.0.I personally reopened the bug until I got tired to see it not fixed. :-)

I think we should be thankful that we have developers instead users developing openSUSE :-) But it would undoubtedly be nice with more users testing, such that issues such as this could have been reported.

Well, the idea of increasing the testing user base is there. Read the opensuse-testing ML, or the archives of -project and -factory looking for my name. I did NOT see an invasion of volunteers though, and in #opensuse-testing on IRC we are about 5-6, two of these guys are from Novell, btw.

...

3) too many things that are broken out of the box on openSUSE (e.g 11.1 disk burning was broken., the release before the package manager was broken)

I don't recognize that at all, but maybe I need the right set of end-users glasses to see through.

Burning CD/DVD was broken in 11.1 at release time, and patched about one month later. About the package manager, it was a pain during the whole 10.x; x > 0 era. I don't think we can forget that! :-) Regards, A. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2009-03-26 at 19:33 +0100, Per Jessen wrote:

Ivan N. Zlatev wrote:

...

Yes this is indeed ridiculous. Samba / Windows Shares browsing doesn't *NOT* work out of the box on openSUSE. The reason is that it's blocked in the Firewall by default.

Presumably Samba runs on a private network, which the firewall is intended to protect from the public network. Sounds like a Firewall configuration issue most of all.

Often the internal network is connected to the outside by a router(*) provided by the ISP (perhaps with WiFi), and can't be considered secure: thus the need for a firewall running on our computers, even on the "internal" network. (*) My ISP hasn't provided a single update for my router for years. Even if it is Linux inside, that can't be considered secure. It doesn't come "secured" out of the box: firewall disabled, common login/pass published on web pages... - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknODooACgkQtTMYHG2NR9VDPACfbH+3XoCEDQiMo1y6yZR0A8Ub iCYAnRSCcbcoodOrhncbShQFvzxxedNe =IAUV -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2009-03-28 at 10:41 -0500, Rajko M. wrote:

...

Often the internal network is connected to the outside by a router(*) provided by the ISP (perhaps with WiFi), and can't be considered secure: thus the need for a firewall running on our computers, even on the "internal" network.

Carlos, you don't put better door on rooms when outside doors are weak. If I can't replace them, for whatever reason, I would reinforce them from inside and keep inside free of obstacles. It is simply lesser work in daily life.

When you live on an apartment, you have a key on the street door, and separate keys on each apartment >:-P

...

It doesn't come "secured" out of the box: firewall disabled, common login/pass published on web pages...

If word firewall doesn't mean NAT than it is default for each router.

This particular router has nat, and also a firewall, which is disabled by default. The firewall should deter people from scanning ports on the router, at least.

Problem is that people forget and misplace login info, and if there would be no way to know defaults, people would avoid to buy device.

Most "secure" devices have a way to reset to defaults. It could reset to a default password, and disable internet till changed, forcing the user to change it from the inside.

I've seen some recent routers with defaults printed on label, so that is changing.

Yes, things should change... - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknOwYEACgkQtTMYHG2NR9X4CwCfSiDT868GKaL4Ome0NbrANnCS JGoAnisQnJ5D0kg90fKqVbs6PqQShjUO =RCvN -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2009-03-28 at 19:30 +0100, Per Jessen wrote:

Carlos E. R. wrote:

...

On Thursday, 2009-03-26 at 19:33 +0100, Per Jessen wrote:

...

Presumably Samba runs on a private network, which the firewall is intended to protect from the public network. Sounds like a Firewall configuration issue most of all.

Often the internal network is connected to the outside by a router(*) provided by the ISP (perhaps with WiFi), and can't be considered secure:

In such a situation I think it is very likely that the router will be NAT'ing, which without any port-forwarding is actually a pretty safe setup.

A hacker could log into the router (telnet), and from there perhaps try telnet or ssh to the internal computers, or simply change the configuration to forward the ports he is interested in. By default, this particular router comes with a known login/pass, and administrative ports open to the outside (supposedly only from IPs belonging to the ISP tech support). Or, they could hack their entry to the wifi on the same router, get a local ip, and try some mischief - actually a chap I know said he actually did this to other people, got inside some windows machines, learned the password to the bank, and had a pip inside. He stopped right there, not doing a real mischief: had he intended to do so, he would have instead logged in from one unprotected neighbour to another one, so that the IP logged would not be his. So, I do not trust those access routers. When mine crashes, it reverts to factory default, which is easily hackeable - and I wouldn't notice till some time.

...

thus the need for a firewall running on our computers, even on the "internal" network.

No, that is the wrong thinking. A firewall is of zero use unless it is in between two networks.

Not quite. SuSEfirewall2 protects the machine it is running on from the network. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknOmwAACgkQtTMYHG2NR9UcKwCghZURlZ/ZC+tAzgvGgmIMsj+E N88An2keuqs5TM/wv46S0uCK0cvhchs6 =JP9j -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2009-03-31 at 18:55 +0200, Per Jessen wrote:

...

A hacker could log into the router (telnet),

How can you even think about security if your router has public telnet access?

I'm not that dumb! I closed it, but the factory defaults leave it open for a range of IPs, supposedly those of the ISP technicians. What I means is that the defaults the router provided by my ISP has, are unsafe, and many users do not even touch them.

...

...

...

thus the need for a firewall running on our computers, even on the "internal" network.

No, that is the wrong thinking. A firewall is of zero use unless it is in between two networks.

Not quite. SuSEfirewall2 protects the machine it is running on from the network.

Still two networks involved - your machine has it's own network (127.0.0.0/8).

Virtually. And some programs are listening on the eth network. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknVVbIACgkQtTMYHG2NR9VhbQCfVHeonsKUx+zdhlsG0ws0Hlpi LOMAnilSdcYqt7dk4zr8Oqlus3mG5ECg =hKye -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Thursday 26 March 2009 01:43:31 pm Alberto Passalacqua wrote:

Did you check if that patch fixes the issues? I still have to try, since I'm currently (\o/) not relying on samba shares :)

That's exactly our problem. We can't see Samba problems. I fire up Windows box once in a few months, but some people would like to have Linux box fit in Windows (tm) world without problems. Like gentleman in article. Sharing files: That means at least one directory is shared. You can drop content without knowing any options, touching any button, adding any users, enabling any ports, and pick that from another computer. I'm sure that will expose all Samba vulnerabilities to LAN, but seriously, since when is Home LAN considered war zone? Printer cooperation: I'm kind of advanced Linux user, and following few articles I found on the net, I still can't print from Windows box direct to cupsd. I don't need it. I tried it only to see why people complain. Wireless: My happy lappy has wireless, thanks to ndiswrapper. Last time I was in the mood to try native Linux stuff (year or so ago) it would configure, it would work better then ndiswrapper, but on next boot there will be no driver. Reconfiguring wireless on each reboot is somewhat unusual procedure. It might be fixed in the meantime, but I don't have to live with "native" driver perks waiting until it grows up. That are few small things that hang as a problem for years. So far I recall, my Samba problem was solved using simple config from Samba by Example, and it worked as described above in Sharing files. Printer was available to anyone on LAN, using a bit expanded samba.config. There are security concerns with such configuration if applied to business environment, but there is no effective default configuration for every occassion. Home LAN is not the same as small business, or corporate one. Sharing configurations is as important as sharing source code, or binaries. It is part where advanced users can help without knowing how to write a single line of code. I think, that if we want to have more users (more of the kind) we should find the easy way to share this. Is it rpm that has only few config files and script that will ask few questions to determine what to do, or just link on the wiki to the server where those files are stored, it is matter of automatization, but it has to be created. I guess Samba would be ideal candidate to begin with. And, no I don't look at Novell guys to do this. They can give advice if there is questions, as they usually do, but this community can do such things. We don't need big guys to catch this fruit. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Rajko M. a écrit :

I guess Samba would be ideal candidate to begin with.

remember samba is *not* activated by default in Windows, or in other word, no folder is shared by default in windows. even more, it's possible when sharing a computer to write anywhere but on the home of an other user - a special shared folder is provided. jdd -- http://www.dodin.net http://valerie.dodin.org http://www.youtube.com/watch?v=t-eic8MSSfM http://www.facebook.com/profile.php?id=1412160445 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Hey, Can we start talking about potential solutions instead of just talking about the issues? :-) Example: Le jeudi 26 mars 2009, à 16:08 -0500, Rajko M. a écrit :

Sharing files: That means at least one directory is shared. You can drop content without knowing any options, touching any button, adding any users, enabling any ports, and pick that from another computer. I'm sure that will expose all Samba vulnerabilities to LAN, but seriously, since when is Home LAN considered war zone?

The user goes in ~/Public with his file manager displays a button "Enable file sharing" for this specific directory. The user clicks on it and the file sharing preferences are opened. (or the user directly looks in the preferences and finds "File Sharing" there) (alternatively, we can just keep the right-click and "Share" menu item for each directory and live happy with it, but I tend to think it's a broken way to share files and prefer to have everything in ~/Public -- this is of course debatable and this is not the immediate object of this mail) In this interface, there's a simple checkbox to enable/disable file sharing. Checking the checkbox would: + use PackageKit to install potential missing packages (installing samba for sharing via smb and apache for sharing via webdav -- most people won't care about which one is used, this can be an advanced user option) + use a YaST PolicyKit interface to properly configure samba for simple file sharing + (no need to do anything as root for webdav since a simple webdav server can be run with apache as the user) + use a YaST PolicyKit interface to open the right ports in the firewall - what is needed for security here? Should it make a difference between a computer on a local network and a computer directly connecter to the world? What about wifi? - for samba, this is a one-time effort - for webdav/apache, this is opening a port per ConsoleKit session (so it should be closed when the ConsoleKit session is closed, and maybe permission should be asked on next session opening if we're in a strict policy environment) Is this workflow missing something? Now, what are we missing from the technical point of view: + we have file sharing preferences + we have PackageKit - we don't have the information "this package is needed if you want to enable this specific feature" (this could arguably be hard-coded, or we could use RPM Provides) + there's an effort to offer a PolicyKit interface to YaST. No idea what is the status of that and if it allows high-level operations like the ones described above. - if samba is already configured on the system, but on a different way, can YaST detect that and do the right magic to add the configuration that would be needed? + I doubt we have anything that can link a specific firewall rule to a ConsoleKit session at the moment. Is this a good solution (I think it could be)? How can it be implemented? + this should be discussed from a security point of view too. If we agree this is what we want to do, which operations are safe to do without a password? Which ones require a password? Do we need some specific text when asking the password explaining the security implications? And guess what? We can even use openFATE to continue this discussion :-) Just open an entry "Streamline file sharing configuration for simple user case". Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

All this is interesting, but how do we manage that in a transparent way in both DE's? Shares in KDE are managed by KDE itself too, which comes with its samba configuration tools, which are not integrated with YaST. Plus, I'm not amazed by the idea of having a public and accessible zone on a default installation. The current behaviour in GNOME is good enough imho, and the user has to follow the same path it follows on Windows. The actual problem is not in the interface, but in samba setup, mainly due to the firewall. If you setup samba server in YaST, it actually works almost out of the box, if the firewall is setup correctly. So I think it is not necessary to redesign the whole interface, create dependencies between YaST and other tools and so on, at least as a first approach. A cleaner guided procedure to configure samba server and the firewall, with the possibility of invoking YaST from the DE GUI to do to the job should be OK, safer, and easier to maintain on the long run. Regards, A. Il giorno ven, 27/03/2009 alle 09.31 +0100, Vincent Untz ha scritto:

Hey,

Can we start talking about potential solutions instead of just talking about the issues? :-)

Example:

Le jeudi 26 mars 2009, à 16:08 -0500, Rajko M. a écrit :

...

Sharing files: That means at least one directory is shared. You can drop content without knowing any options, touching any button, adding any users, enabling any ports, and pick that from another computer. I'm sure that will expose all Samba vulnerabilities to LAN, but seriously, since when is Home LAN considered war zone?

The user goes in ~/Public with his file manager displays a button "Enable file sharing" for this specific directory. The user clicks on it and the file sharing preferences are opened. (or the user directly looks in the preferences and finds "File Sharing" there)

(alternatively, we can just keep the right-click and "Share" menu item for each directory and live happy with it, but I tend to think it's a broken way to share files and prefer to have everything in ~/Public -- this is of course debatable and this is not the immediate object of this mail)

In this interface, there's a simple checkbox to enable/disable file sharing. Checking the checkbox would:

+ use PackageKit to install potential missing packages (installing samba for sharing via smb and apache for sharing via webdav -- most people won't care about which one is used, this can be an advanced user option) + use a YaST PolicyKit interface to properly configure samba for simple file sharing + (no need to do anything as root for webdav since a simple webdav server can be run with apache as the user) + use a YaST PolicyKit interface to open the right ports in the firewall - what is needed for security here? Should it make a difference between a computer on a local network and a computer directly connecter to the world? What about wifi? - for samba, this is a one-time effort - for webdav/apache, this is opening a port per ConsoleKit session (so it should be closed when the ConsoleKit session is closed, and maybe permission should be asked on next session opening if we're in a strict policy environment)

Is this workflow missing something?

Now, what are we missing from the technical point of view:

+ we have file sharing preferences + we have PackageKit - we don't have the information "this package is needed if you want to enable this specific feature" (this could arguably be hard-coded, or we could use RPM Provides) + there's an effort to offer a PolicyKit interface to YaST. No idea what is the status of that and if it allows high-level operations like the ones described above. - if samba is already configured on the system, but on a different way, can YaST detect that and do the right magic to add the configuration that would be needed? + I doubt we have anything that can link a specific firewall rule to a ConsoleKit session at the moment. Is this a good solution (I think it could be)? How can it be implemented? + this should be discussed from a security point of view too. If we agree this is what we want to do, which operations are safe to do without a password? Which ones require a password? Do we need some specific text when asking the password explaining the security implications?

And guess what? We can even use openFATE to continue this discussion :-) Just open an entry "Streamline file sharing configuration for simple user case".

Vincent

-- Les gens heureux ne sont pas pressés.

-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Saturday 28 March 2009 07:53:23 am James Tremblay aka SLEducator wrote:

... Continue to fail on Joe Plumber and piss him off. He doesn't have nor does he want firewall training!

That is the problem. He finds other things than computer exciting. For him computer is just appliance. If oversecured and overcomplicated setup procedure prevents him from using computer, he applies simple logic that we all apply to other devices. Cheapo doesn't work, you get what you pay for. He goes out and buy something that does work. I already had guy that did just that. He trashed old rig with openSUSE, went out and bought another computer. That is why I'll test ways (configurations) and hopefully over time find some that work. Current is to much for me and I'm very much Do It Yourself type. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Friday 27 March 2009 03:31:32 am Vincent Untz wrote:

Hey,

Can we start talking about potential solutions instead of just talking about the issues? :-)

We got to talk about both. If you don't know there is an issue, you don't know that you need solution :-)

Example:

Le jeudi 26 mars 2009, à 16:08 -0500, Rajko M. a écrit :

...

Sharing files: That means at least one directory is shared. You can drop content without knowing any options, touching any button, adding any users, enabling any ports, and pick that from another computer. I'm sure that will expose all Samba vulnerabilities to LAN, but seriously, since when is Home LAN considered war zone?

The user goes in ~/Public with his file manager displays a button "Enable file sharing" for this specific directory. The user clicks on it and the file sharing preferences are opened. (or the user directly looks in the preferences and finds "File Sharing" there)

We can't assume that every user will want that ~Public exist [1] and for majority that simply accept defaults it would be better to have this enabled by default. As jdd said, it will be clear to almost anybody what is the purpose. From "help desk" perspective it is easier to tell user: "Drop files that you want to share in ~Public, and pick it up on another computer".

(alternatively, we can just keep the right-click and "Share" menu item for each directory and live happy with it, but I tend to think it's a broken way to share files and prefer to have everything in ~/Public -- this is of course debatable and this is not the immediate object of this mail)

I can only agree. There is no reason to create ability to make any directory shared. Moving files in Linux is shorter than a blink within /home partition, so having one directory Public is fine. That should be actually default configuration. That is also problem with default samba.conf, it is revealing too much.

In this interface, there's a simple checkbox to enable/disable file sharing. Checking the checkbox would:

It could be simple button like network icon in GNOME. Press it and ~Public is visible. Press again and ~Public is off line. Icon change indicates status.

+ use PackageKit to install potential missing packages (installing samba for sharing via smb and apache for sharing via webdav -- most people won't care about which one is used, this can be an advanced user option)

This can be done with pattern, something like Home Network. Although, I'm not sure how to create one. Concept of patterns and their dependencies combined with package dependencies is not for everyone.

+ use a YaST PolicyKit interface to properly configure samba for simple file sharing + (no need to do anything as root for webdav since a simple webdav server can be run with apache as the user) + use a YaST PolicyKit interface to open the right ports in the firewall

When you mentioned PolicyKit, you finally lost me. Why simple /etc/smb.conf as part of rpm would not satisfy basic needs. Webdav is something that I never tried. I tried public-html, but it doesn't work without fiddling with conf files.

- what is needed for security here? Should it make a difference between a computer on a local network and a computer directly connecter to the world? What about wifi?

It should be difference. Local net is not the same as Internet. Wifi is maybe different, but no one can defend home owner that leaves doors open. All that distro has to do is to warn that door should be locked, tell how to that and than user is on its own. On the other hand, current status is like keeping door locked and key hidden so far that one needs weeks to find it.

- for samba, this is a one-time effort

- for webdav/apache, this is opening a port per ConsoleKit session (so it should be closed when the ConsoleKit session is closed, and maybe permission should be asked on next session opening if we're in a strict policy environment)

Is this workflow missing something?

I added my comments. Other should be free add more.

Now, what are we missing from the technical point of view: ... And guess what? We can even use openFATE to continue this discussion :-) Just open an entry "Streamline file sharing configuration for simple user case".

There are 2 I mentioned in previous post. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2009-03-27 at 01:04 +0100, Marcus Meissner wrote:

Set the firewall to "Internal" if you are working internally, like when you have SMB shares.

That would assume the internal network is safe, which in my limited experience is not. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknOEJ4ACgkQtTMYHG2NR9UWCQCfUJsF4h16MMt0Yx1ipoNJqBf9 vA4An0YfzrcdhDzLCriRnJ3seLPeghjj =KDdu -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Il giorno sab, 28/03/2009 alle 16.52 +0100, Jan Ritzerfeld ha scritto:

If it is not safe, you will not use SMB!

That's true in theory. But what about laptops for example, which are more and more used as desktop replacements also in offices? You need SMB for sharing files and printers when at office, where probably your internal network is safe, but you use the same network interface when your are elsewhere, which is probably not safe. A solution might be to have profiles for the two situations, but it still requires the user intervention to switch them. Another could be to associate a certain firewall configuration to a specific network. Would this be feasible in a safe way? Regards, A. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Il giorno sab, 28/03/2009 alle 19.33 +0100, Per Jessen ha scritto:

Alberto, that has been going on for at least 10 years without adding any new security risks.

How? Maybe you can explain, so we all learn something, and maybe write a tutorial on how to set these things up? :-)

...

You need SMB for sharing files and printers when at office, where probably your internal network is safe, but you use the same network interface when your are elsewhere, which is probably not safe.

If you are in an corporate environment with a laptop, someone (i.e. the sysadmin) will sort our the issues for you. (for himself rather).

That's an assumption, which is not always true. I mean, not everywhere there is a sysadmin managing your laptop, and you might anyway use that laptop in unprotected networks, with your firewall ports open (public wifis, at home with a DSL modem that doesn't work as firewall, and so on). How do you solve the problem there? Regards, A. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Saturday 28 March 2009 01:33:53 pm Per Jessen wrote:

...

You need SMB for sharing files and printers when at office, where probably your internal network is safe, but you use the same network interface when your are elsewhere, which is probably not safe.

If you are in an corporate environment with a laptop, someone (i.e. the sysadmin) will sort our the issues for you.  (for himself rather).

Initial post was about user that has to sort that out by himself. Besides, I'm still reading how to setup Samba. I can see shares set in Linux, but I can't write to them.

I think Jan was spot on with "If it is not safe, you will not use SMB!".

The problem is that safety is good if it is comfortable to carry every day. Cloth is not as good protector as tin, but trough the time it won. Besides, if entering the house would be as complicated as entering computer, we would be very safe inside. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2009-03-28 at 16:52 +0100, Jan Ritzerfeld wrote:

Am Samstag, 28. März 2009 schrieb Carlos E. R.:

...

On Friday, 2009-03-27 at 01:04 +0100, Marcus Meissner wrote:

...

Set the firewall to "Internal" if you are working internally, like when you have SMB shares.

That would assume the internal network is safe, which in my limited experience is not.

If it is not safe, you will not use SMB!

Can you convince all windows users not to use windows, because it is not safe? When you do, then I also will not use samba >:-P - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknOvuoACgkQtTMYHG2NR9Wm8gCfWeV0ws4m21RVWFhmVNnCrYfw mpUAnRRusQg9S3p+BWYxpewn1k4Il5BN =yFH3 -----END PGP SIGNATURE-----

Am Sonntag, 29. März 2009 schrieb Carlos E. R.:

On Saturday, 2009-03-28 at 16:52 +0100, Jan Ritzerfeld wrote:

...

Am Samstag, 28. März 2009 schrieb Carlos E. R.:

...

On Friday, 2009-03-27 at 01:04 +0100, Marcus Meissner wrote:

...

Set the firewall to "Internal" if you are working internally, like when you have SMB shares.

That would assume the internal network is safe, which in my limited experience is not.

If it is not safe, you will not use SMB!

Can you convince all windows users not to use windows, because it is not safe? When you do, then I also will not use samba >:-P

I meant that you do not want to use SMB in a non-trusted network. Gruß Jan -- It's fascinating how memory diffuses fact. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Sunday 29 March 2009 08:08:19 am Carlos E. R. wrote:

On Sunday, 2009-03-29 at 11:16 +0200, Jan Ritzerfeld wrote:

...

...

...

If it is not safe, you will not use SMB!

Can you convince all windows users not to use windows, because it is not safe? When you do, then I also will not use samba >:-P

I meant that you do not want to use SMB in a non-trusted network.

And I that it is not optional.

Carlos, in short, you are not average user. You can select higher security, you know how and if not you will learn. You are old class of Linux users that have strong Do It Yourself attitude. Joe the Plumber, can't. When he comes home in the evening he wants to turn on device and have it working. He throws away stuff that doesn't work and has no warranty, goes out and buys new. Different model if brand created clearly distinguishable properties, or different brand if model doesn't fulfill expectations, like it advertises multimedia while there is none in the box, or connectivity, while you got to go trough hops to get it working. People here are very spoiled consumers. If you say something is replacement for Windows, but without problems that they have, it better be that way, or you lost customer for good. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Am Sonntag, 29. März 2009 schrieb Carlos E. R.:

[...] My firewall is configured to permit samba only for certain IPs - but as you say, I'm perhaps not the average user :-) [...]

And you do think, that this is secure? It is not! It is snake oil like a personal firewall is. When the network is none-trusted, as you assumed, IP addresses can be easily spoofed. Gruß Jan -- Never trust anyone that volunteers to assume authority. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org