By default, CentOS v5 requires a user's password when the system wakes up from the screensaver. This can be disabled by each user, but how can I disable this system-wide? Many of my users forget to do this, which results in workstations being locked up.
Bob
On Wed, 19 Jan 2011 at 11:44am, Bob Eastbrook wrote
By default, CentOS v5 requires a user's password when the system wakes up from the screensaver. This can be disabled by each user, but how can I disable this system-wide? Many of my users forget to do this, which results in workstations being locked up.
Ctrl-Alt-Bksp will fix that right up. I'm not a big fan of users leaving workstations unsecured when they walk away.
On Wed, Jan 19, 2011 at 9:46 PM, Joshua Baker-LePain jlb17@duke.edu wrote:
On Wed, 19 Jan 2011 at 11:44am, Bob Eastbrook wrote
By default, CentOS v5 requires a user's password when the system wakes up from the screensaver. This can be disabled by each user, but how can I disable this system-wide? Many of my users forget to do this, which results in workstations being locked up.
Ctrl-Alt-Bksp will fix that right up. I'm not a big fan of users leaving workstations unsecured when they walk away.
--
Don't you mean CTRL+ALT+DEL?
I don't think the OP wanted a plaster, he wants a solution :)
On Wed, 19 Jan 2011 at 9:49pm, Rudi Ahlers wrote
On Wed, Jan 19, 2011 at 9:46 PM, Joshua Baker-LePain jlb17@duke.edu wrote:
On Wed, 19 Jan 2011 at 11:44am, Bob Eastbrook wrote
By default, CentOS v5 requires a user's password when the system wakes up from the screensaver. This can be disabled by each user, but how can I disable this system-wide? Many of my users forget to do this, which results in workstations being locked up.
Ctrl-Alt-Bksp will fix that right up. I'm not a big fan of users leaving workstations unsecured when they walk away.
Don't you mean CTRL+ALT+DEL?
That'd work too, but the reboot is unnecessary. Ctrl-Alt-Bksp will just kill the X server (and thus the user's session). X will then respawn itself and restart GDM.
I don't think the OP wanted a plaster, he wants a solution :)
One person's solution is another's giant gaping security hole.
On 1/19/11 11:49 AM, Rudi Ahlers wrote:
On Wed, Jan 19, 2011 at 9:46 PM, Joshua Baker-LePain jlb17@duke.edu wrote:
On Wed, 19 Jan 2011 at 11:44am, Bob Eastbrook wrote
By default, CentOS v5 requires a user's password when the system wakes up from the screensaver. This can be disabled by each user, but how can I disable this system-wide? Many of my users forget to do this, which results in workstations being locked up.
Ctrl-Alt-Bksp will fix that right up. I'm not a big fan of users leaving workstations unsecured when they walk away.
--
Don't you mean CTRL+ALT+DEL?
I don't think the OP wanted a plaster, he wants a solution :)
I believe that CTRL-ALT-Bksp will restart X, not the computer. On restart of X you should be welcomed with the login screen.
Sean Hart wrote:
On 1/19/11 11:49 AM, Rudi Ahlers wrote:
On Wed, Jan 19, 2011 at 9:46 PM, Joshua Baker-LePain jlb17@duke.edu wrote:
On Wed, 19 Jan 2011 at 11:44am, Bob Eastbrook wrote
By default, CentOS v5 requires a user's password when the system wakes up from the screensaver. This can be disabled by each user, but how can I disable this system-wide? Many of my users forget to do this, which results in workstations being locked up.
Ctrl-Alt-Bksp will fix that right up. I'm not a big fan of users leaving workstations unsecured when they walk away.
Don't you mean CTRL+ALT+DEL?
I don't think the OP wanted a plaster, he wants a solution :)
I believe that CTRL-ALT-Bksp will restart X, not the computer. On restart of X you should be welcomed with the login screen.
But the locked screensaver wants the *same* password that you log in with. I'm having trouble understanding the problem... or is it that many of the users *never* log out?
mark
On Wed, Jan 19, 2011 at 03:18:37PM -0500, m.roth@5-cent.us wrote:
Sean Hart wrote:
On 1/19/11 11:49 AM, Rudi Ahlers wrote:
I believe that CTRL-ALT-Bksp will restart X, not the computer. On restart of X you should be welcomed with the login screen.
Note that in later versions of X, this is disabled by default--this was an xorg decisions, apparently, they felt too many were typing it by mistake.
It can be enabled with an entry in /etc/X11/xorg.conf (It can, apparently, also be enabled with a Gnome GUI, but not using Gnome, I've forgotten what it is.)
I suspect that in CentOS 6, it will no longer work, not sure about 5.x at this point.
On Wed, 2011-01-19 at 15:29 -0500, Scott Robbins wrote:
On Wed, Jan 19, 2011 at 03:18:37PM -0500, m.roth@5-cent.us wrote:
Sean Hart wrote:
On 1/19/11 11:49 AM, Rudi Ahlers wrote:
I believe that CTRL-ALT-Bksp will restart X, not the computer. On restart of X you should be welcomed with the login screen.
Note that in later versions of X, this is disabled by default--this was an xorg decisions, apparently, they felt too many were typing it by mistake.
It can be enabled with an entry in /etc/X11/xorg.conf (It can, apparently, also be enabled with a Gnome GUI, but not using Gnome, I've forgotten what it is.)
I suspect that in CentOS 6, it will no longer work, not sure about 5.x at this point.
I can confirm it does not work on RHEL 6 Workstation.
On Wed, Jan 19, 2011 at 03:18:37PM -0500, m.roth@5-cent.us wrote:
But the locked screensaver wants the *same* password that you log in with. I'm having trouble understanding the problem... or is it that many of the users *never* log out?
The locked screensaver will be killed along with the rest of the X session with ctrl-alt-backspace. When [kgx]dm restarts it will present a fresh login window.
Are the screensavers not smart enough to intercept ctrl-alt-bksp?
For the OP: what's the goal behind preventing an X session from locking? Perhaps there is a more elegant solution than simply disabling it.
--keith
On Wed, Jan 19, 2011 at 10:35 PM, Keith Keller kkeller@wombat.san-francisco.ca.us wrote:
For the OP: what's the goal behind preventing an X session from locking? Perhaps there is a more elegant solution than simply disabling it.
--keith
-- kkeller@wombat.san-francisco.ca.us
It probably depends on his environment. If it's an office where people actually work for money and need to address client issues then I'm sure your colleagues won't be please if you make them loose all their work just to be an arrogant IT manager who wants to prove a point.
I don't know about you, but a user leaving his desk (for any purpose, other than going home) doesn't cause a security risk. I trust all our staff, and when Andrew goes on lunch I expect him to leave his PC unlocked. 1. It's our property and he should have any personal stuff on there, as per our NDA, that could cause problem. 2. If a client, which Andrew was busy with phones in, I or one of the other staff members would need access to that work.
So, in such a case I do think the OP has a valid question and it could be addressed more professionally than to restart X, or even the PC just to prove a point.
P.S. And I don't know the answer either.....
On Thu, 20 Jan 2011, Rudi Ahlers wrote:
I don't know about you, but a user leaving his desk (for any purpose, other than going home) doesn't cause a security risk. I trust all our staff, and when Andrew goes on lunch I expect him to leave his PC unlocked.
I think I see things differently. Allowing others to access your account *is* a security risk. It potentially opens confidential data open to other people, and leaves that specific user open to abuse through people using their machine. You might as well just pin your passwords on the notice board and be done. After all, you trust all your staff.
- If a client, which Andrew was busy with phones in, I or one of the
other staff members would need access to that work.
That's a data storage issue. Appropriate software systems should ensure you have access to the data you need from your own account. Anyone's free to use my machine while I'm not there, but they're certainly not free to use my login.
So, in such a case I do think the OP has a valid question and it could be addressed more professionally than to restart X, or even the PC just to prove a point.
P.S. And I don't know the answer either.....
For gnome how about something like:
gconftool-2 --direct \ --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type bool \ --set /apps/gnome-screensaver/lock_enabled false
jh
On Thu, Jan 20, 2011 at 12:00 PM, John Hodrien J.H.Hodrien@leeds.ac.uk wrote:
I think I see things differently. Allowing others to access your account *is* a security risk. It potentially opens confidential data open to other people, and leaves that specific user open to abuse through people using their machine. You might as well just pin your passwords on the notice board and be done. After all, you trust all your staff.
I don't agree with that, sorry.
A few years ago one of our staff members decided his salary isn't good enough so he started a side-line business, on our company time. He stole some of our client's data (contact details, emails, and even contracts) and sold it to 3rd parties. This went on for about 6 months before we actually realized what was going on.
Needless to say, he was fined heavily and sent to jail for 3 years. So, I don't care if you feel the PC is your's, as long as it's a company PC, with company data and company property, we will take a look at the data on it.
I'm not talking about your home / private PC, that's an altogether different story.
On 20/01/2011 11:55, Rudi Ahlers wrote:
On Thu, Jan 20, 2011 at 12:00 PM, John HodrienJ.H.Hodrien@leeds.ac.uk wrote:
I think I see things differently. Allowing others to access your account *is* a security risk. It potentially opens confidential data open to other people, and leaves that specific user open to abuse through people using their machine. You might as well just pin your passwords on the notice board and be done. After all, you trust all your staff.
I don't agree with that, sorry.
A few years ago one of our staff members decided his salary isn't good enough so he started a side-line business, on our company time. He stole some of our client's data (contact details, emails, and even contracts) and sold it to 3rd parties. This went on for about 6 months before we actually realized what was going on.
Needless to say, he was fined heavily and sent to jail for 3 years. So, I don't care if you feel the PC is your's, as long as it's a company PC, with company data and company property, we will take a look at the data on it.
I'm not talking about your home / private PC, that's an altogether different story.
I disagree. There are two points here.
A user account should belong to the person who has been assigned that account. They are the only person who should be able to use that account. This is critical is you are going to have an audit trail as to who did what and when. If someone else is able to use an account, be it by not locking unattended workstations or by sharing of passwords then the staff member who went to jail would have had a very good defence. Now, the data that is owned by an account is a completely different matter, this is why computer file systems have both access control lists as well as owners defined for the files, as well as access and modification times. Any _data_ on a business system belongs to the business and the access control list defines who has been given the responsibility and permissions to access that data.
Data and Accounts are distinct, and the policies regarding their use should be distinct too.
On Thursday, January 20, 2011 06:02:38 am Giles Coochey wrote:
Data and Accounts are distinct, and the policies regarding their use should be distinct too.
+1.
The third 'A' of triple-A (AAA) is accountability. If you share accounts you defeat accountability. This has nothing to do with data access, or user home directory data access; yes, there should be mechanisms in place for monitoring. But those mechanisms need their own accountability, too. The access should be done only by an account authorized to do so.
Without accountability, authentication and authorization don't mean a whole lot.
Giles Coochey wrote:
[...]
A user account should belong to the person who has been assigned that account. They are the only person who should be able to use that
You are conflating "access" and "ownership". The company should own the machine and the data. Only persons authorized by the company should have access. That should include the user to whom the account is assigned, and a limited number of "trusted" persons with administration priviledges. Ultimately, the company must have access to all information on an "as needed" basis, which should be rare.
The rest of your argument stands.
[...]
Data and Accounts are distinct, and the policies regarding their use should be distinct too.
Well stated.
Mike
On Thu, 20 Jan 2011, Rudi Ahlers wrote:
I think I see things differently. Allowing others to access your account *is* a security risk. It potentially opens confidential data open to other people, and leaves that specific user open to abuse through people using their machine. You might as well just pin your passwords on the notice board and be done. After all, you trust all your staff.
I don't agree with that, sorry.
A few years ago one of our staff members decided his salary isn't good enough so he started a side-line business, on our company time. He stole some of our client's data (contact details, emails, and even contracts) and sold it to 3rd parties. This went on for about 6 months before we actually realized what was going on.
Yes, and with poor security like you're describing, you can actually mask your activity under someone else's account. Having weak security on accounts (and leaving them unlocked definitely counts as that) makes this sort of abuse much easier to hide. If you can't reasonably trust (and there are various reasons why you should never 100% trust this) that activity under an account maps back to an individual, you've really diluted the quality of your evidence.
Needless to say, he was fined heavily and sent to jail for 3 years. So, I don't care if you feel the PC is your's, as long as it's a company PC, with company data and company property, we will take a look at the data on it.
You're very much mixing two issues. I have no objection with admins having access to machines and data. Some random colleague being able to pop open a file browser and download some company confidential material, or send an email to a client, or download some illegal material to my desktop? No thanks.
An account is a personal account that should not be shared. You shouldn't tell someone else your password, nor should you let them use your account unsupervised. This is a rule that's often relaxed (shared accounts, admin accounts etc.), but relaxing it doesn't typically improve security, it just sometimes makes things easier to do. But you should always be aware of the compromises you're making by doing so.
jh
On Thu, 2011-01-20 at 11:05 +0000, John Hodrien wrote:
An account is a personal account that should not be shared.
+1
Also, at least in the United States, locking a PC / workstation after 15 minutes of idle is a requirement of PCI/DSS - which your company almost certainly agreed to if you process credit card or other payment information. HIPPA, FERPA, and friends have similar requirements / strong-recommendations.
Ask a competent lawyer and he'll/she'll tell you to lock unattended workstations.
This has nothing to do with auditing the access to or usage of data - that is a separate issue.
On 20/01/2011 13:12, Adam Tauno Williams wrote:
On Thu, 2011-01-20 at 11:05 +0000, John Hodrien wrote:
An account is a personal account that should not be shared.
+1
Also, at least in the United States, locking a PC / workstation after 15 minutes of idle is a requirement of PCI/DSS - which your company almost certainly agreed to if you process credit card or other payment information. HIPPA, FERPA, and friends have similar requirements / strong-recommendations.
Ask a competent lawyer and he'll/she'll tell you to lock unattended workstations.
This has nothing to do with auditing the access to or usage of data - that is a separate issue.
Yes, what you mention then becomes a legal compliance issue.
Note, however, that many small companies completely outsource credit card payment by using third-party processing (e.g. Worldpay). This means they have no card data environment and don't need to comply with PCI/DSS in their offices. Even companies that do in-house card payment processing only have to enforce PCI/DSS in their CDE.
I can't speak for HIPPA, SOX etc... but automatic locking is part of IT best practice.
On Thu, 2011-01-20 at 14:08 +0100, Giles Coochey wrote:
On 20/01/2011 13:12, Adam Tauno Williams wrote:
On Thu, 2011-01-20 at 11:05 +0000, John Hodrien wrote:
An account is a personal account that should not be shared.
+1 Also, at least in the United States, locking a PC / workstation after 15 minutes of idle is a requirement of PCI/DSS - which your company almost certainly agreed to if you process credit card or other payment information. HIPPA, FERPA, and friends have similar requirements / strong-recommendations. Ask a competent lawyer and he'll/she'll tell you to lock unattended workstations. This has nothing to do with auditing the access to or usage of data - that is a separate issue
Yes, what you mention then becomes a legal compliance issue. Note, however, that many small companies completely outsource credit card payment by using third-party processing (e.g. Worldpay). This means they have no card data environment and don't need to comply with PCI/DSS in their offices. Even companies that do in-house card payment processing only have to enforce PCI/DSS in their CDE.
Correct; I'm just of the stick-to-as-much-of-the-strictest-requirements-in-as-much-of-the-network-as-possible school. It helps avoid debates and issues about where and where not a requirement applies [some of the clauses are pretty vague]. Call it CYA if you like.
While such standards are much-maligned I actually find them useful as a tool for pushing for better security against crowds that don't like password change requirements, etc... The standards speak a language "suits" understand and to some degree believe in [or at least fear, which works well enough].
I can't speak for HIPPA, SOX etc... but automatic locking is part of IT best practice.
Adam Tauno Williams wrote:
On Thu, 2011-01-20 at 14:08 +0100, Giles Coochey wrote:
On 20/01/2011 13:12, Adam Tauno Williams wrote:
On Thu, 2011-01-20 at 11:05 +0000, John Hodrien wrote:
An account is a personal account that should not be shared.
<snip>
While such standards are much-maligned I actually find them useful as a tool for pushing for better security against crowds that don't like password change requirements, etc... The standards speak a language "suits" understand and to some degree believe in [or at least fear, which works well enough].
Yeah, well, the problem is they're pushing more frequent password changes, while, according the the other admin I work with, NIST only recommends every two *years*. ESPECIALLY if you do *not* have single sign-on everywhere, frequent password changes, and required a lot of difference between the current password and the new one, *and* not coming anywhere near the last year or two's worth of passwords is worse than useless, it's counterproductive, since it makes social engineering much easier, since *everyone* will be writing down their passwords.
I can't speak for HIPPA, SOX etc... but automatic locking is part of IT best practice.
HIPPA, and PII (Personal Information Identifier), and PHI (Personal Health Information) is very, *very* much need-to-know *only*, and violation is punishable by termination, and possibly criminal action.
mark, who works for a US federal contractor with the US gov't, and had to get a "position of trust"* clearance for the job....
* Which I assume entitles me to see bottom secrets, or maybe bargain basement secrets.... <g>
On Jan 20, 2011, at 9:23 AM, m.roth@5-cent.us wrote:
Adam Tauno Williams wrote:
On Thu, 2011-01-20 at 14:08 +0100, Giles Coochey wrote:
On 20/01/2011 13:12, Adam Tauno Williams wrote:
On Thu, 2011-01-20 at 11:05 +0000, John Hodrien wrote:
An account is a personal account that should not be shared.
<snip> > While such standards are much-maligned I actually find them useful as a > tool for pushing for better security against crowds that don't like > password change requirements, etc... The standards speak a language > "suits" understand and to some degree believe in [or at least fear, > which works well enough].
Yeah, well, the problem is they're pushing more frequent password changes, while, according the the other admin I work with, NIST only recommends every two *years*. ESPECIALLY if you do *not* have single sign-on everywhere, frequent password changes, and required a lot of difference between the current password and the new one, *and* not coming anywhere near the last year or two's worth of passwords is worse than useless, it's counterproductive, since it makes social engineering much easier, since *everyone* will be writing down their passwords.
I can't speak for HIPPA, SOX etc... but automatic locking is part of IT best practice.
HIPPA, and PII (Personal Information Identifier), and PHI (Personal Health Information) is very, *very* much need-to-know *only*, and violation is punishable by termination, and possibly criminal action.
mark, who works for a US federal contractor with the US gov't, and had to get a "position of trust"* clearance for the job....
- Which I assume entitles me to see bottom secrets, or maybe bargain
basement secrets.... <g>
The whole 90 day password change recommendation came about because it was calculated to be the median number of days it would take to perform a brute password crack on a offline copy of the password hashes given a sufficiently complex password standard and a high-end desktop computer.
With Amazon's cloud services now I guess they'll have to cut it down to 7 days, or require finger print or retinal eye scans...
-Ross
Ross Walker wrote:
On Jan 20, 2011, at 9:23 AM, m.roth@5-cent.us wrote:
Adam Tauno Williams wrote:
On Thu, 2011-01-20 at 14:08 +0100, Giles Coochey wrote:
On 20/01/2011 13:12, Adam Tauno Williams wrote:
On Thu, 2011-01-20 at 11:05 +0000, John Hodrien wrote:
An account is a personal account that should not be shared.
<snip> > While such standards are much-maligned I actually find them useful as a > tool for pushing for better security against crowds that don't like > password change requirements, etc... The standards speak a language > "suits" understand and to some degree believe in [or at least fear, > which works well enough].
Yeah, well, the problem is they're pushing more frequent password changes, while, according the the other admin I work with, NIST only
recommends
every two *years*. ESPECIALLY if you do *not* have single sign-on everywhere, frequent password changes, and required a lot of difference between the current password and the new one, *and* not coming anywhere near the last year or two's worth of passwords is worse than useless, it's counterproductive, since it makes social engineering much easier,
since
*everyone* will be writing down their passwords.
<snip>
The whole 90 day password change recommendation came about because it was calculated to be the median number of days it would take to perform a brute password crack on a offline copy of the password hashes given a sufficiently complex password standard and a high-end desktop computer.
With Amazon's cloud services now I guess they'll have to cut it down to 7 days, or require finger print or retinal eye scans...
"You have not logged on in one hour: your account is locked; please have it unlocked, and change your password...."
mark "it's even safer if you unplug it from the network"
On Thursday, January 20, 2011 09:36:09 am Ross Walker wrote:
With Amazon's cloud services now I guess they'll have to cut it down to 7 days, or require finger print or retinal eye scans...
Fingerprints are too easily faked. Mythbusters did it in a 'Crime and Mythdemeanors' episode a few years ago.
Lamar Owen wrote:
On Thursday, January 20, 2011 09:36:09 am Ross Walker wrote:
With Amazon's cloud services now I guess they'll have to cut it down to 7 days, or require finger print or retinal eye scans...
Fingerprints are too easily faked. Mythbusters did it in a 'Crime and Mythdemeanors' episode a few years ago.
I can beat that: I read, a month or so ago, how a bunch of elementary school kids discovered that wet Gummi Bears would hold a fingerprint, *and* (they didn't understand this) have more or less the same electrical conductivity....
mark, who has to stare into the scanner when he goes into the datacenter
On Thursday, January 20, 2011 12:03:27 pm m.roth@5-cent.us wrote:
Lamar Owen wrote:
Fingerprints are too easily faked. Mythbusters did it in a 'Crime and Mythdemeanors' episode a few years ago.
I can beat that: I read, a month or so ago, how a bunch of elementary school kids discovered that wet Gummi Bears would hold a fingerprint, *and* (they didn't understand this) have more or less the same electrical conductivity....
Gummi bears are a pretty good simulcrum for ballistics gel, which is what MB used.
MB did it differently, though, in that they lifted the fingerprint from an object the subject touched, that was not gel. IIRC, it was a CD case. It's a good episode; see https://secure.wikimedia.org/wikipedia/en/wiki/MythBusters_%282006_season%29... for a synopsis of that portion. (If you're wondering why the link is to an https site.... well, I'm running HTTPSAnywhere..... :-) )
Two-factor security should be standard, really. Fingerprint plus ID card, or fingerprint plus keycode, etc. One factor being something you uniquely have, and the other being either something you have or something you know.
Speaking of, with PAM being standard in CentOS, has anyone here done physical security (like datacenter doors and such) where the controller is open source and usable on CentOS? I'd be interested in kitting such a setup for our datacenters here.
Lamar Owen wrote:
On Thursday, January 20, 2011 12:03:27 pm m.roth@5-cent.us wrote:
Lamar Owen wrote:
Fingerprints are too easily faked. Mythbusters did it in a 'Crime and Mythdemeanors' episode a few years ago.
I can beat that: I read, a month or so ago, how a bunch of elementary school kids discovered that wet Gummi Bears would hold a fingerprint, *and* (they didn't understand this) have more or less the same electrical conductivity....
<snip>
Two-factor security should be standard, really. Fingerprint plus ID card, or fingerprint plus keycode, etc. One factor being something you uniquely have, and the other being either something you have or something you know.
<snip> We (the Feds) are using PIV cards, which have passkeys, and, of course, the username. I prefer what I have from my employer: the RSA keyfobs. No trouble at all, *and* you need the username, keyfob and a pin.
mark
On Thursday, January 20, 2011 01:57:54 pm m.roth@5-cent.us wrote:
We (the Feds) are using PIV cards, which have passkeys, and, of course, the username. I prefer what I have from my employer: the RSA keyfobs. No trouble at all, *and* you need the username, keyfob and a pin.
Our co-lo site is using fingerprint plus HID Corp cards.
I'm not familiar with the RSA keyfobs, though.
Lamar Owen wrote:
On Thursday, January 20, 2011 01:57:54 pm m.roth@5-cent.us wrote:
We (the Feds) are using PIV cards, which have passkeys, and, of course, the username. I prefer what I have from my employer: the RSA keyfobs. No trouble at all, *and* you need the username, keyfob and a pin.
Our co-lo site is using fingerprint plus HID Corp cards.
I'm not familiar with the RSA keyfobs, though.
Oh. They have a six digit number that changes every single minute. It's synchronized with the authentication server. To log onto my company website, for example, so I can do my timesheet, I put in my username, then a pin, followed by the current six digit code.
So, you need three pieces of information, and one constantly changes.
mark
On Thu, Jan 20, 2011 at 12:03 PM, m.roth@5-cent.us wrote:
Lamar Owen wrote:
On Thursday, January 20, 2011 09:36:09 am Ross Walker wrote:
With Amazon's cloud services now I guess they'll have to cut it down to 7 days, or require finger print or retinal eye scans...
Fingerprints are too easily faked. Mythbusters did it in a 'Crime and Mythdemeanors' episode a few years ago.
I can beat that: I read, a month or so ago, how a bunch of elementary school kids discovered that wet Gummi Bears would hold a fingerprint, *and* (they didn't understand this) have more or less the same electrical conductivity....
Fortunately I don't go sticking my fingers in wet gummy bears, so that risk is mitigated!
While finger prints can be faked, it often requires access to the finger to fake. I haven't heard of someone lifting a latent oil print and creating a fake out of that. I'm sure with enough ingenuity it can be done. Then again if someone is that intent on accessing your data, well I'm sure they could figure another way as well...
-Ross
On 01/20/2011 02:53 PM, Ross Walker wrote:
Fortunately I don't go sticking my fingers in wet gummy bears, so that risk is mitigated!
While finger prints can be faked, it often requires access to the finger to fake. I haven't heard of someone lifting a latent oil print and creating a fake out of that.
http://www.theregister.co.uk/2002/05/16/gummi_bears_defeat_fingerprint_senso...
Now you have.
On Thursday, January 20, 2011 05:53:14 pm Ross Walker wrote:
I haven't heard of someone lifting a latent oil print and creating a fake out of that. I'm sure with enough ingenuity it can be done.
Let me repeat: that is exactly what MythBusters did in the episode I referenced, 'Crime and Mythdemeanors 2' which aired a few years ago. The print was Grant's, and it was lifted from a CD case, duplicated into ballistics gel using a partially obscured process that included PC board etching and print cleanup in a graphics editor, and successfully opened the fingerprint door lock (as well as logging in to a PC). The narrator in the episode did state that one critical part of the process was omitted to keep that episode from being a HOWTO, but it probably wouldn't take a rocket scientist to figure it out.
On Thu, Jan 20, 2011 at 5:53 PM, Ross Walker rswwalker@gmail.com wrote:
On Thu, Jan 20, 2011 at 12:03 PM, m.roth@5-cent.us wrote:
I can beat that: I read, a month or so ago, how a bunch of elementary school kids discovered that wet Gummi Bears would hold a fingerprint, *and* (they didn't understand this) have more or less the same electrical conductivity....
Fortunately I don't go sticking my fingers in wet gummy bears, so that risk is mitigated!
While finger prints can be faked, it often requires access to the finger to fake. I haven't heard of someone lifting a latent oil print and creating a fake out of that. I'm sure with enough ingenuity it can be done. Then again if someone is that intent on accessing your data, well I'm sure they could figure another way as well...
Nope.
I found this link in a reference from 2002, and have seen nothing to indicate any significant improvement of fingerprint scanners to ignore gelatin based fake fingerprints, overlaid on a living person's finger to fool the electrostatic or thermal sensors of some sensors, and and with the fingeprints transferred from a Xerox of a police or other official fingerprint.
http://www.schneier.com/crypto-gram-0205.html
This has me laughing my tail off at the insistence on including fingerprint authorization as a default in RHEL 6, and the difficulty of extracting the daemons and utilities from the base image. Too many scattered RPM dependencies for other utilities. It's actually now a default "enabled" feature in anaconda for kickstart installations.
Giles Coochey wrote:
[...]
I can't speak for HIPPA, SOX etc... but automatic locking is part of IT best practice.
I can. I did a contract job a few years ago to achieve HIPPA compliance with some pharmacy software. I inserted time limits with logout, screen information blanking, and RAM data overwriting in order to comply.
SOX I don't know about.
Mike
Mike McCarty wrote:
Giles Coochey wrote:
[...]
I can't speak for HIPPA, SOX etc... but automatic locking is part of IT best practice.
I can. I did a contract job a few years ago to achieve HIPPA compliance with some pharmacy software. I inserted time limits with logout, screen information blanking, and RAM data overwriting in order to comply.
Yup. We've had training, both from the gov't and from the company on protecting PII data, including making sure that your monitor isn't visible by anyone in the hall, etc.
mark
On Thu, 2011-01-20 at 14:18 -0600, Mike McCarty wrote:
Giles Coochey wrote:
[...]
I can't speak for HIPPA, SOX etc... but automatic locking is part of IT best practice.
I can. I did a contract job a few years ago to achieve HIPPA compliance with some pharmacy software. I inserted time limits with logout, screen information blanking, and RAM data overwriting in order to comply.
What happened to SSL (Encryption)? Gee the MPI just hit the world.
John
JohnS wrote:
On Thu, 2011-01-20 at 14:18 -0600, Mike McCarty wrote:
Giles Coochey wrote:
[...]
I can't speak for HIPPA, SOX etc... but automatic locking is part of IT best practice.
I can. I did a contract job a few years ago to achieve HIPPA compliance with some pharmacy software. I inserted time limits with logout, screen information blanking, and RAM data overwriting in order to comply.
What happened to SSL (Encryption)? Gee the MPI just hit the world.
This is on software which ran as POS stuff.
Mike
On Thu, 2011-01-20 at 20:13 -0600, Mike McCarty wrote:
This is on software which ran as POS stuff.
Yea but the catch is it is left up to YOU being responsible for what happens on that network. Very candid HIPPA states only `data at rest` does not have to be. In my state I live in I am the responsible party and could be held liable. OK we getting OT now.
John
Greetings,
On 1/21/11, JohnS jses27@gmail.com wrote:
On Thu, 2011-01-20 at 20:13 -0600, Mike McCarty wrote:
This is on software which ran as POS stuff.
hmm... how about a vlock -a (or inverse thereof) wrapper?
Regards,
Rajagopal
Rajagopal Swaminathan wrote:
Greetings,
On 1/21/11, JohnS jses27@gmail.com wrote:
On Thu, 2011-01-20 at 20:13 -0600, Mike McCarty wrote:
This is on software which ran as POS stuff.
hmm... how about a vlock -a (or inverse thereof) wrapper?
We wanted to log the user out of the POS application, not lock out of the machine. That also doesn't address overwriting of sensitive material in RAM. Also, it was with SCO, not Linux. It should really be thought of more as an embedded application. Upon boot up, the first thing run was the app, and that occurred automatically. The users were not computer savvy. In fact, the ones who thought they had some savvy were the ones causing most of the problems, by messing up the configuration.
One guy liked to rename directories to suit his fancy.
Mike
On 01/20/2011 02:55 AM, Rudi Ahlers wrote:
I don't agree with that, sorry.
A few years ago one of our staff members decided his salary isn't good enough so he started a side-line business, on our company time. He stole some of our client's data (contact details, emails, and even contracts) and sold it to 3rd parties. This went on for about 6 months before we actually realized what was going on.
Needless to say, he was fined heavily and sent to jail for 3 years. So, I don't care if you feel the PC is your's, as long as it's a company PC, with company data and company property, we will take a look at the data on it.
I'm not talking about your home / private PC, that's an altogether different story.
You are talking completely different issues. Allowing anyone walking past a machine to sit down and do whatever they want (which is stupid) is not in the least the same as having administrative access and auditing by IT (which is smart).
If you don't have full administrative access to the machine *independent* of people's day-to-day login accounts you are doing it wrong and need to hire a competent IT admin - because your current one doesn't know what heck they are doing.
On Thu, Jan 20, 2011 at 3:47 PM, Jerry Franz jfranz@freerun.com wrote:
On 01/20/2011 02:55 AM, Rudi Ahlers wrote:
I don't agree with that, sorry.
A few years ago one of our staff members decided his salary isn't good enough so he started a side-line business, on our company time. He stole some of our client's data (contact details, emails, and even contracts) and sold it to 3rd parties. This went on for about 6 months before we actually realized what was going on.
Needless to say, he was fined heavily and sent to jail for 3 years. So, I don't care if you feel the PC is your's, as long as it's a company PC, with company data and company property, we will take a look at the data on it.
I'm not talking about your home / private PC, that's an altogether different story.
You are talking completely different issues. Allowing anyone walking past a machine to sit down and do whatever they want (which is stupid) is not in the least the same as having administrative access and auditing by IT (which is smart).
If you don't have full administrative access to the machine *independent* of people's day-to-day login accounts you are doing it wrong and need to hire a competent IT admin - because your current one doesn't know what heck they are doing.
-- Benjamin Franz _______________________________________________
Benjamin, I'm sorry to say this, but you're wrong!
Now, since we're doing the name-calling thing, let's get that out of the way.
Sometimes you need to access a PC of a staff member who is busy with something right now. And I'm not talking about administrative access. Sure, I can access any PC via root login, and frankly for that matter I can also reset any user's password via root login.
The message I'm trying to bring across is that users in the company shouldn't have passwords which admin doesn't know, or can't access. The PC's and data, well at least in our company, is the property of the company. Making it more difficult for an engineer to gain access to a user's PC automatically arises suspicion
On Thu, 20 Jan 2011, Rudi Ahlers wrote:
Benjamin, I'm sorry to say this, but you're wrong!
I'm fairly sure he's not.
Now, since we're doing the name-calling thing, let's get that out of the way.
Sometimes you need to access a PC of a staff member who is busy with something right now. And I'm not talking about administrative access. Sure, I can access any PC via root login, and frankly for that matter I can also reset any user's password via root login.
No, you don't. You don't need access to their account, you need access to data. If the data you need access to is inaccessible from your account, that's your issue.
The message I'm trying to bring across is that users in the company shouldn't have passwords which admin doesn't know, or can't access. The PC's and data, well at least in our company, is the property of the company. Making it more difficult for an engineer to gain access to a user's PC automatically arises suspicion
You really should be talking about data not accounts here, as that's what you're interested in as a company. You certainly don't want to know all the passwords.
jh
On 20/01/2011 17:11, Rudi Ahlers wrote:
The message I'm trying to bring across is that users in the company shouldn't have passwords which admin doesn't know, or can't access. The PC's and data, well at least in our company, is the property of the company. Making it more difficult for an engineer to gain access to a user's PC automatically arises suspicion
Hi Rudi,
Your stance on this is counter-intuitive to me, are you able to cite any good reference which recommends that administrators know user passwords?
On Thu, Jan 20, 2011 at 6:29 PM, Giles Coochey giles@coochey.net wrote:
On 20/01/2011 17:11, Rudi Ahlers wrote:
The message I'm trying to bring across is that users in the company shouldn't have passwords which admin doesn't know, or can't access. The PC's and data, well at least in our company, is the property of the company. Making it more difficult for an engineer to gain access to a user's PC automatically arises suspicion
Hi Rudi,
Your stance on this is counter-intuitive to me, are you able to cite any good reference which recommends that administrators know user passwords?
--
No, I can't. But I've been running a hosting & development company for 9 years now and this is the first problem I get out of the way right on the first day of an employees job.
I'm personally involved in the accounts department (when I actually get time) since I want to know what goes on in my company. I also work close with the developers when needed. We trust everyone in the office, and being it an open-plan office, it's easy to see if someone is at someone else's desk when they're not supposed to be. Staff logoff and shutdown every night, so that's not an issue.
But, it is a big issue when a staff member goes on leave, or even just on lunch and switch-off their cellphones and I can't get hold of them to get a password to login to a PC if I need to. The account PC, for that matter is encrypted, with no network access so one needs to be in front if it to access the data.
User accounts also doesn't mean much to me. I know how it sounds, but I care more about the data than the user's account. As long as I can access whatever I want, whenever I want.
Rudi Ahlers wrote:
[...]
User accounts also doesn't mean much to me. I know how it sounds, but I care more about the data than the user's account. As long as I can access whatever I want, whenever I want.
ISTM that you have "control issues". Access to data is what counts, and you've got that by your own statement. Since that's the case, I suggest that there isn't going to be any change in your stance, no matter what arguments get presented. You have an emotional attachment to this issue, and rational argument isn't going to make progress.
What might make a difference would be addressing the emotional content of your statements. That's something better done in another venue, I think.
The bottom line with you seems to be "because I _want_ it that way."
I suspect that no rational argument is going to change the desire to feel the degree of control over your machines and employees that you have.
That's not necessarily a criticism, BTW. In this particular case, it seems excessive to me. However, you are you, and "you" (your company) have paid for something, and you want a certain degree of control.
I like to control what's on my machine, too, as another thread reveals.
Mike
On 1/20/2011 10:11 AM, Rudi Ahlers wrote:
Benjamin, I'm sorry to say this, but you're wrong!
Now, since we're doing the name-calling thing, let's get that out of the way.
Sometimes you need to access a PC of a staff member who is busy with something right now. And I'm not talking about administrative access. Sure, I can access any PC via root login, and frankly for that matter I can also reset any user's password via root login.
The message I'm trying to bring across is that users in the company shouldn't have passwords which admin doesn't know, or can't access. The PC's and data, well at least in our company, is the property of the company. Making it more difficult for an engineer to gain access to a user's PC automatically arises suspicion
That actually sounds very strange. Are there any published references for the concept that individual passwords should be shared instead of an administrator using his own granted privileges when accessing data owned by someone else? And if group access is commonly needed, shouldn't the data be group-accessible, both in protection and location?
Are you working around some software constraint here? I can understand both sharing of physical workstations (with different logins) and sharing common data, but don't see why you'd ever want one person to pretend to be someone else by sharing a login.
On Thu, Jan 20, 2011 at 11:11 AM, Rudi Ahlers Rudi@softdux.com wrote:
Sometimes you need to access a PC of a staff member who is busy with something right now. And I'm not talking about administrative access. Sure, I can access any PC via root login, and frankly for that matter I can also reset any user's password via root login.
The message I'm trying to bring across is that users in the company shouldn't have passwords which admin doesn't know, or can't access. The PC's and data, well at least in our company, is the property of the company. Making it more difficult for an engineer to gain access to a user's PC automatically arises suspicion
You clearly work in an insecure environment.
No one should have access to anyone else's login. I have no admin privileges over my desktop. If I need something installed or uninstalled, I have to ask the Windows desktop support team who'll access my box remotely after I accept their request to a access my box in a popup on my screen. Of course, the Windows server support team can access my roaming profile on their boxes but (I presume since this is what we do and I don't know any of them to ask them) they'd have to justify that acess.
There's absolutely no reason to "access a PC of a staff member who is busy", that's terrible practice; and there's absolutely no way that anyone should know anyone else's password (a punishable violation of IT policy in our environment).
On Thu, Jan 20, 2011 at 6:44 PM, Tom H tomh0665@gmail.com wrote:
You clearly work in an insecure environment.
By who's definition? The fact that you're PC is connected to the internet place you in the same environment :)
No one should have access to anyone else's login. I have no admin privileges over my desktop. If I need something installed or uninstalled, I have to ask the Windows desktop support team who'll access my box remotely after I accept their request to a access my box in a popup on my screen. Of course, the Windows server support team can access my roaming profile on their boxes but (I presume since this is what we do and I don't know any of them to ask them) they'd have to justify that acess.
Yes, IT staff on a Windows Domain can access everyone's accounts, without their passwords or consent. Does it make it more secure? Yes. And No. IT staff can go rouge as well, just bear that in mind. Reminds me of a previous company I used to work for many years ago.
Some of the IT admin scanned all incoming mail, especially if they contained any attachments. They casually copied whatever attachments they wanted to their own desktops, which was more often move clips, cracked games, music, pr0n, etc. Do you think management knew about this? Nope.
Is it less safe than your environment? Really? Can you honestly tell me this doesn't happen in your company?
There's absolutely no reason to "access a PC of a staff member who is busy", that's terrible practice; and there's absolutely no way that anyone should know anyone else's password (a punishable violation of IT policy in our environment).
True, and that's not what I said either. Both the OP and I am trying to say that sometimes you need to get onto a PC when the user is not actually there.
And it's quite clear that all company's policies differ. Probably for a good reason since what works for one company doesn't work for another company.
IF, on the other hand I worked at a financial institution or something like that then the security would have been more strict. I don't see the need for it in our office.
On Thu, Jan 20, 2011 at 11:52 AM, Rudi Ahlers Rudi@softdux.com wrote:
On Thu, Jan 20, 2011 at 6:44 PM, Tom H tomh0665@gmail.com wrote:
You clearly work in an insecure environment.
By who's definition? The fact that you're PC is connected to the internet place you in the same environment :)
Yes, we've all heard the joke that the only secure computer is one that is turned off. But my comment was not meant as a joke.
By insecure, I mean that you don't mind that employee masquerades as another on your company's network. You therefore have no security and no accountability.
No one should have access to anyone else's login. I have no admin privileges over my desktop. If I need something installed or uninstalled, I have to ask the Windows desktop support team who'll access my box remotely after I accept their request to a access my box in a popup on my screen. Of course, the Windows server support team can access my roaming profile on their boxes but (I presume since this is what we do and I don't know any of them to ask them) they'd have to justify that access.
Yes, IT staff on a Windows Domain can access everyone's accounts, without their passwords or consent. Does it make it more secure? Yes. And No. IT staff can go rouge as well, just bear that in mind. Reminds me of a previous company I used to work for many years ago.
Some of the IT admin scanned all incoming mail, especially if they contained any attachments. They casually copied whatever attachments they wanted to their own desktops, which was more often move clips, cracked games, music, pr0n, etc. Do you think management knew about this? Nope.
Is it less safe than your environment? Really? Can you honestly tell me this doesn't happen in your company?
You're confusing, as you have throughout this thread, an employee assuming someone's logon/identity on the network with an administrator accessing data on the servers that they manage.
No one can or should be able to logon to the network with someone else's credentials.
We have, AFAIK, two security teams that go through server logs and support tickets to reconcile them and to check that we aren't logging to boxes that we aren't supposed to have logged on to, checking whether we used su or sudo for a valid reason, and what we commands we've run while logged on. So we can't just go through data, confidential or otherwise, out of curiosity or with some bad intentions.
So, no, there's no such activity on our network. Eleven years ago, I worked at a firm where the Exchange admins used to copy all the attachments that dealers and brokers received and burn DVDs for themselves, their friends, and for sale (!) with any porn-related files. There's no way that this is still happening.
There's absolutely no reason to "access a PC of a staff member who is busy", that's terrible practice; and there's absolutely no way that anyone should know anyone else's password (a punishable violation of IT policy in our environment).
True, and that's not what I said either.
Both the OP and I am trying to say that sometimes you need to get onto a PC when the user is not actually there.
So why would you not want them to have password-locked screensavers.
You either want to access that employees account or you want to access data on that computer by switching users. I've already covered the former and the latter simply shows that you're keeping data locally rather than on a server; not a good practice either...
IF, on the other hand I worked at a financial institution or something like that then the security would have been more strict. I don't see the need for it in our office.
I worked a few years ago, in between finance jobs, at a publisher who had similar rules. This is a standard for any properly-run IT department.
Rudi Ahlers wrote:
On Thu, Jan 20, 2011 at 12:00 PM, John Hodrien J.H.Hodrien@leeds.ac.uk wrote:
I think I see things differently. Allowing others to access your account *is* a security risk. It potentially opens confidential data open to other people, and leaves that specific user open to abuse through people using their machine. You might as well just pin your passwords on the notice board and be done. After all, you trust all your staff.
I don't agree with that, sorry.
A few years ago one of our staff members decided his salary isn't good enough so he started a side-line business, on our company time. He stole some of our client's data (contact details, emails, and even contracts) and sold it to 3rd parties. This went on for about 6 months before we actually realized what was going on.
The computer belongs to the company, and the information on it _should_ belong to the company (though what people put on computers can't be completely monitored), but keeping one employee out of another's accounts is important for a variety of reasons.
That does not preclude access to the machine's content. Anyone with root access should be able to do that. You shouldn't have to log in AS THAT USER in order to access the computer's content.
Mike
On Thursday, January 20, 2011 03:11:00 pm Mike McCarty wrote:
That does not preclude access to the machine's content. Anyone with root access should be able to do that. You shouldn't have to log in AS THAT USER in order to access the computer's content.
Although I have seen in the case of Windows, installed to NTFS, and set with 'make your files private' when you first set up a password, that if even if you log in as Administrator you can't necessarily see all users' files, at least not through file sharing. It has been a long time since I've put that to the test on the local console.
Makes it a pain to do whole machine virus scans from the Administrator account, and makes it a bigger pain to do backups using the semi-documented $ shares when file sharing is enabled in the firewall.
I've never experienced that on Linux, but it is possible to set up the SELinux policy in a way that 'ordinary' root can't do everything, that you have to be in a different context.
John Hodrien wrote:
On Thu, 20 Jan 2011, Rudi Ahlers wrote:
I don't know about you, but a user leaving his desk (for any purpose, other than going home) doesn't cause a security risk. I trust all our staff, and when Andrew goes on lunch I expect him to leave his PC unlocked.
I think I see things differently. Allowing others to access your account *is* a security risk. It potentially opens confidential data open to other people, and leaves that specific user open to abuse through people using their machine. You might as well just pin your passwords on the notice board and be done. After all, you trust all your staff.
This is not a supposition, I've seen it happen. I worked at a company where one guy disabled his keyboard locker. One day he left for lunch. When he came back, Security escorted him to HR, where he was asked to explain why he sent several racist e-mails all over the company. He had "a few days off" while they investigated the incident, and the culprit was found. The culprit thought it was all just a prank, and that's what was intended, but both of them got in lots of trouble. Official memos to everyone followed.
At home, I keep my keyboard locked the instant I leave it because of potential security breaches, using the little "lock screen (sic)" button on the pop up menu on the left. Just about the only GUI button I use.
OTOH, I have cats :-)
Mike
Mike McCarty wrote:
John Hodrien wrote:
On Thu, 20 Jan 2011, Rudi Ahlers wrote:
<snip>
At home, I keep my keyboard locked the instant I leave it because of potential security breaches, using the little "lock screen (sic)" button on the pop up menu on the left. Just about the only GUI button I use.
OTOH, I have cats :-)
Danger, Will Robinson! Cat typing detected!
mark "what, you don't want $23,524.07 charged to your credit card at catsactuallyruletheworld.org?"
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Mike McCarty Sent: Thursday, January 20, 2011 9:08 PM To: CentOS mailing list Subject: Re: [CentOS] How to disable screen locking system-wide?
OTOH, I have cats :-)
Funny you should mention that. One of my cockatiels once almost managed to delete a file for me at home, wandering and pecking on the keyboard. Beats me how he managed... Since then I always lock the screen when leaving the computer and the birds are out in the room. Saving yourself some aggravation... Kinda'...
On Thu, Jan 20, 2011 at 2:00 AM, John Hodrien J.H.Hodrien@leeds.ac.uk wrote:
For gnome how about something like:
gconftool-2 --direct \ --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type bool \ --set /apps/gnome-screensaver/lock_enabled false
Many thanks. That did the trick.
Bob
On Thu, Jan 20, 2011 at 4:00 AM, Rudi Ahlers Rudi@softdux.com wrote:
It probably depends on his environment. If it's an office where people actually work for money and need to address client issues then I'm sure your colleagues won't be please if you make them loose all their work just to be an arrogant IT manager who wants to prove a point.
I don't know about you, but a user leaving his desk (for any purpose, other than going home) doesn't cause a security risk. I trust all our staff, and when Andrew goes on lunch I expect him to leave his PC unlocked.
- It's our property and he should have any personal stuff on there,
as per our NDA, that could cause problem.
- If a client, which Andrew was busy with phones in, I or one of the
other staff members would need access to that work.
So, in such a case I do think the OP has a valid question and it could be addressed more professionally than to restart X, or even the PC just to prove a point.
P.S. And I don't know the answer either.....
In our environment, leaving your desk without locking your computer/screen is punished with a disciplinary hearing and three such hearings result in dismissal. Having one person using another's account is considered a security risk.
I don't know the exact path but you can use gconftool-2 (or gconf-editor as a GUI) to set the screensaver not to lock (and mimick doing so by changing the screensaver preferences in "System-Preferences-Screensaver").
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Tom H Sent: Thursday, January 20, 2011 1:03 PM To: CentOS mailing list Subject: Re: [CentOS] How to disable screen locking system-wide?
In our environment, leaving your desk without locking your computer/screen is punished with a disciplinary hearing and three such hearings result in dismissal. Having one person using another's account is considered a security risk.
Sounds kinda' harsh. May I ask what industry this is in?
I don't know the exact path but you can use gconftool-2 (or gconf-editor as a GUI) to set the screensaver not to lock (and mimick doing so by changing the screensaver preferences in "System-Preferences-Screensaver").
That's a per-user setting you describe, right?
On Thu, 20 Jan 2011 at 11:00am, Rudi Ahlers wrote
It probably depends on his environment. If it's an office where people actually work for money and need to address client issues then I'm sure your colleagues won't be please if you make them loose all their work just to be an arrogant IT manager who wants to prove a point.
*snip*
So, in such a case I do think the OP has a valid question and it could be addressed more professionally than to restart X, or even the PC just to prove a point.
I was going to leave this alone, but I feel this lowers to the level of personal attacks and I'd like to address that. Yes, my response was a bit glib (and tongue-in-cheek, which obviously didn't come across correctly). But that doesn't mean that the reasoning behind it isn't valid in some situations, and it certainly doesn't make me arrogant or unprofessional. As others have pointed out, there are industries and workplaces where any unlocked, unattended workstation is a major security risk. Please don't assume that your use case is everybody else's. And please keep it civil. Thanks.
We now return you to your regularly scheduled CentOS list programming (no pun intended).
Joshua Baker-LePain wrote:
On Thu, 20 Jan 2011 at 11:00am, Rudi Ahlers wrote
It probably depends on his environment. If it's an office where people
<snip>
situations, and it certainly doesn't make me arrogant or unprofessional. As others have pointed out, there are industries and workplaces where any unlocked, unattended workstation is a major security risk. Please don't
<snip> Excuse me, but when I was in college, I heard the spiel about not leaving workstations unlocked, if only because some idiots would get cute and do something from your terminal to embarrass you, and/or aggravate someone else.
mark, who logs off his system at home every night and every morning... (and the the only other resident, the fish, is too lazy to flop out of the tank to the keyboard....)
On Thu, 20 Jan 2011, m.roth@5-cent.us wrote:
Excuse me, but when I was in college, I heard the spiel about not leaving workstations unlocked, if only because some idiots would get cute and do something from your terminal to embarrass you, and/or aggravate someone else.
cat >> .bashrc <<EOF echo Logging off is important and fun sleep 5 echo Logging off is important and fun sleep 5 echo Logging off is important and fun sleep 5 EOF
jh
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Joshua Baker-LePain Sent: Thursday, January 20, 2011 4:49 PM To: CentOS mailing list Subject: Re: [CentOS] How to disable screen locking system-wide?
I was going to leave this alone, but I feel this lowers to the level of personal attacks and I'd like to address that. Yes, my response was a bit glib (and tongue-in-cheek, which obviously didn't come across correctly).
But that doesn't mean that the reasoning behind it isn't valid in some situations, and it certainly doesn't make me arrogant or unprofessional. As others have pointed out, there are industries and workplaces where any unlocked, unattended workstation is a major security risk. Please don't assume that your use case is everybody else's. And please keep it civil.
Suddenly came to think of Mordac, the IT-preventer in the Dilbert strip. ;-)
One a more serious note, personally, if I run across an unlocked workstation and there's nobody around, I take a few seconds to start up Notepad (if Windows) or OpenOffice (if linux) and type in a message like "If I'd been a bad guy, your data would all have been gone and your homepage been set to www.bestialporn.com. //Your friendly Sysadmin" in real big letters, and then maximize the window, and lastly activated the (password-protected) screensaver, before I walked away.
I've done this a few times over the years, and the message has usually been acknowledged and accepted with no questions asked.
No need to restart any machines; that's just mean. Although I have been dreaming about doing that... ;-)
On 19/01/2011 21:35, Keith Keller wrote:
Are the screensavers not smart enough to intercept ctrl-alt-bksp?
For the OP: what's the goal behind preventing an X session from locking? Perhaps there is a more elegant solution than simply disabling it.
Screensavers can't intercept... X gets the message and processes it before the Screensaver sees anything
If you want to disable CTRL-ALT-BACKSPACE use the X option "DontZap" in your X configuration.
On Wed, Jan 19, 2011 at 12:18 PM, m.roth@5-cent.us wrote:
But the locked screensaver wants the *same* password that you log in with. I'm having trouble understanding the problem... or is it that many of the users *never* log out?
Yes, users will sign onto a workstation, and then disappear somewhere in the building. They usually forget that they're logged on, which means the workstation is unusable by anyone else for several days.
Restarting the X server is one solution, but it will kill any running jobs.
If user Bob sees that Alice is logged on, but not doing anything, then Bob could safely log Alice out.
Bob
On Thursday 20 Jan 2011 22:26:08 Bob Eastbrook wrote:
On Wed, Jan 19, 2011 at 12:18 PM, m.roth@5-cent.us wrote:
But the locked screensaver wants the *same* password that you log in with. I'm having trouble understanding the problem... or is it that many of the users *never* log out?
Yes, users will sign onto a workstation, and then disappear somewhere in the building. They usually forget that they're logged on, which means the workstation is unusable by anyone else for several days.
Restarting the X server is one solution, but it will kill any running jobs.
I'm not sure about GNOME or if that's available in version currently shipped in CentOS but in KDE the screensaver allows you to switch user, i.e. leave the currently logged on user's session running and start a new one for another user. That seems like a better solution if possible, no?
on 13:11 Fri 21 Jan, Michael Gliwinski (Michael.Gliwinski@henderson-group.com) wrote:
On Thursday 20 Jan 2011 22:26:08 Bob Eastbrook wrote:
On Wed, Jan 19, 2011 at 12:18 PM, m.roth@5-cent.us wrote:
But the locked screensaver wants the *same* password that you log in with. I'm having trouble understanding the problem... or is it that many of the users *never* log out?
Yes, users will sign onto a workstation, and then disappear somewhere in the building. They usually forget that they're logged on, which means the workstation is unusable by anyone else for several days.
Restarting the X server is one solution, but it will kill any running jobs.
I'm not sure about GNOME or if that's available in version currently shipped in CentOS but in KDE the screensaver allows you to switch user, i.e. leave the currently logged on user's session running and start a new one for another user. That seems like a better solution if possible, no?
Or, so long as your graphics card doesn't kill console access, go old school:
- Switch to console. - Log into console. - Launch X.
The problem here is the hanging console session, which you should kill.
Better: Institute a policy that abandoned desktop sessions are fair game to be killed. As with hot stoves and children, the lesson would be learned after a few experiences.
Systems work should be handled remotely via ssh (or VNC), within screen session, or via cronjobs.
Another useful feature would be to have an auto-logoff set after a certain amount of inactivity. This doesn't seem to be available within GNOME, so you'd probably have to homebrew it.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Joshua Baker-LePain Sent: Wednesday, January 19, 2011 8:47 PM To: CentOS mailing list Subject: Re: [CentOS] How to disable screen locking system-wide?
By default, CentOS v5 requires a user's password when the system wakes up from the screensaver. This can be disabled by each user, but how can I disable this system-wide? Many of my users forget to do this, which results in workstations being locked up.
Ctrl-Alt-Bksp will fix that right up. I'm not a big fan of users leaving workstations unsecured when they walk away.
Wouldn't that kill any programs, or whatever, the user has running?
On Jan 19, 2011, at 2:44 PM, Bob Eastbrook baconeater789@gmail.com wrote:
By default, CentOS v5 requires a user's password when the system wakes up from the screensaver. This can be disabled by each user, but how can I disable this system-wide? Many of my users forget to do this, which results in workstations being locked up.
Bob _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Jan 19, 2011, at 2:44 PM, Bob Eastbrook baconeater789@gmail.com wrote:
By default, CentOS v5 requires a user's password when the system wakes up from the screensaver. This can be disabled by each user, but how can I disable this system-wide? Many of my users forget to do this, which results in workstations being locked up.
Let's try this again...
KDE has a multi-user x login feature that allows another user to start a new session keeping the existing session active.
It might take a little config mod'ing to get it working, but it works. It works best if there is lots of RAM.
-Ross
On Thu, 20 Jan 2011, Ross Walker wrote:
On Jan 19, 2011, at 2:44 PM, Bob Eastbrook baconeater789@gmail.com wrote:
By default, CentOS v5 requires a user's password when the system wakes up from the screensaver. This can be disabled by each user, but how can I disable this system-wide? Many of my users forget to do this, which results in workstations being locked up.
Let's try this again...
KDE has a multi-user x login feature that allows another user to start a new session keeping the existing session active.
It might take a little config mod'ing to get it working, but it works. It works best if there is lots of RAM.
So does gnome (another gconf key: /apps/gnome-screensaver/user_switch_enabled). Not tried it on CentOS 5, but it works okay on Fedora 12. You have to be careful not to end up with everybody logged in everywhere.
jh
On Jan 20, 2011, at 9:18 AM, John Hodrien J.H.Hodrien@leeds.ac.uk wrote:
On Thu, 20 Jan 2011, Ross Walker wrote:
On Jan 19, 2011, at 2:44 PM, Bob Eastbrook baconeater789@gmail.com wrote:
By default, CentOS v5 requires a user's password when the system wakes up from the screensaver. This can be disabled by each user, but how can I disable this system-wide? Many of my users forget to do this, which results in workstations being locked up.
Let's try this again...
KDE has a multi-user x login feature that allows another user to start a new session keeping the existing session active.
It might take a little config mod'ing to get it working, but it works. It works best if there is lots of RAM.
So does gnome (another gconf key: /apps/gnome-screensaver/user_switch_enabled). Not tried it on CentOS 5, but it works okay on Fedora 12. You have to be careful not to end up with everybody logged in everywhere.
I wonder if there is an auto logoff idle timeout feature?
That would help reduce orphaned sessions. Set it for 8 hours of idle, then auto-logoff.
-Ross
Ross Walker wrote:
On Jan 20, 2011, at 9:18 AM, John Hodrien J.H.Hodrien@leeds.ac.uk wrote:
On Thu, 20 Jan 2011, Ross Walker wrote:
On Jan 19, 2011, at 2:44 PM, Bob Eastbrook baconeater789@gmail.com wrote:
By default, CentOS v5 requires a user's password when the system wakes up from the screensaver. This can be disabled by each user, but how can I disable this system-wide? Many of my users forget to do this, which results in workstations being locked up.
<snip>
I wonder if there is an auto logoff idle timeout feature?
That would help reduce orphaned sessions. Set it for 8 hours of idle, then auto-logoff.
8? I'd think 2, long enough for a long meeting, or a 1 or 2 drink lunch.
mark
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Ross Walker Sent: Thursday, January 20, 2011 3:27 PM To: CentOS mailing list Cc: CentOS mailing list Subject: Re: [CentOS] How to disable screen locking system-wide?
I wonder if there is an auto logoff idle timeout feature?
That would help reduce orphaned sessions. Set it for 8 hours of idle, then auto-logoff.
Now that would be neat on public and semi-public machines over here!
On 1/20/2011 8:18 AM, John Hodrien wrote:
KDE has a multi-user x login feature that allows another user to start a new session keeping the existing session active.
It might take a little config mod'ing to get it working, but it works. It works best if there is lots of RAM.
So does gnome (another gconf key: /apps/gnome-screensaver/user_switch_enabled). Not tried it on CentOS 5, but it works okay on Fedora 12. You have to be careful not to end up with everybody logged in everywhere.
Why is everyone stuck at the console of one particular workstation? The point of a multiuser, networked OS is that you can have as many logins as you want from wherever you want. I almost never log in directly at the console of a linux box unless it is broken - or at least the one where my desktop sessions run.
On Thursday 20 January 2011 09:14, Ross Walker wrote:
On Jan 19, 2011, at 2:44 PM, Bob Eastbrook baconeater789@gmail.com wrote:
By default, CentOS v5 requires a user's password when the system wakes up from the screensaver. This can be disabled by each user, but how can I disable this system-wide? Many of my users forget to do this, which results in workstations being locked up.
Let's try this again...
KDE has a multi-user x login feature that allows another user to start a new session keeping the existing session active.
And if that doesn't work you could always;
Press CTRL+ALT+F2-6 Logon Start a new X session with 'statrx -- :1'
On Thu, Jan 20, 2011 at 09:51:28AM -0500, Robert Spangler wrote:
On Thursday 20 January 2011 09:14, Ross Walker wrote:
KDE has a multi-user x login feature that allows another user to start a new session keeping the existing session active.
And if that doesn't work you could always;
Press CTRL+ALT+F2-6 Logon Start a new X session with 'statrx -- :1'
There is (IIRC) a subtle difference between these two: the former will attempt to execute ~/.xsession, whereas the latter will attempt to execute ~/.xinitrc. If you have neither of these files it shouldn't make much difference, but if you have one, or have both but are different, it might not result in what the user expects. (It's obviously an easy fix if you know about it, but not at all obvious if you don't.)
--keith
By default, CentOS v5 requires a user's password when the system wakes up from the screensaver. This can be disabled by each user, but how can I disable this system-wide? Many of my users forget to do this, which results in workstations being locked up.
Instead of removing the lock on your workstations (big security risk as others have mentioned), why not rather activate the 'user switch' button?
If you really need to access a workstation, you can then log in as another user (e.g. admin user) and then do what you want (which may involve killing the guilty session).
In gconf-editor, you find this option under: /apps/gnome-screensaver/user_switch_enabled
You can then probably apply it system-wide using recommendations of this thread (I haven't tested it).
I quickly scanned through the thread, so maybe somebody suggested that already, sorry for the repeat in that case.
A bit OT, but something related that I discovered recently: you can explicitly start the screensaver (and thus the lock) with Ctrl+Alt+L (instead of looking for the button in the GNOME menu).
-
Adam Tauno Williams -
b.j. mcclure -
Bob Eastbrook -
Dr. Ed Morbius -
Giles Coochey -
Gordon Messmer -
Jerry Franz -
John Hodrien -
JohnS -
Joshua Baker-LePain -
Keith Keller -
Lamar Owen -
Les Mikesell -
m.roth＠5-cent.us -
Mathieu Baudier -
Michael Gliwinski -
Mike McCarty -
Nico Kadel-Garcia -
Rajagopal Swaminathan -
Robert Spangler -
Ross Walker -
Rudi Ahlers -
Scott Robbins -
Sean Hart -
Sorin Srbu -
Tom H