Caching credentials is disabled by default[1]. Even when credential caching is
enabled, the cache is only ever readable by root, the hashes are
*never* exposed to the system. FYI, the hash is a salted sha512.
Ah. Much better.
What leads you to believe the cached credentials can be
On Fri, 2014-02-28 at 14:42 +, Nordgren, Bryce L -FS wrote:
Caching credentials is disabled by default[1]. Even when credential caching
is
enabled, the cache is only ever readable by root, the hashes are
*never* exposed to the system. FYI, the hash is a salted sha512.
Ah. Much
On Fri, Feb 28, 2014 at 09:56:26AM -0500, Simo Sorce wrote:
On Fri, 2014-02-28 at 14:42 +, Nordgren, Bryce L -FS wrote:
Caching credentials is disabled by default[1]. Even when credential
caching is
enabled, the cache is only ever readable by root, the hashes are
*never* exposed
Offline password caching is also optional and a different method.
In this case the actual password is maintained in the kernel keyring
in locked memory until the machine goes online and can acquire a TGT.
On success it is deleted.
however it doesn't really matter from an evil-root
Some further reading material about operating in a security model where you
accept that things are already compromised:
* CISecurity did a good job on the Kerberos benchmark that was written:
http://benchmarks.cisecurity.org/downloads/show-single/index.cfm?file=mitkerberos110.100
* Two Factor
On Fri, 2014-02-28 at 17:27 +, Nordgren, Bryce L -FS wrote:
Am I overlooking something, or is this likely to be an effective means
of delegating small project support while sideboarding potential Evil?
Well, there area always caveats, mostly that you will find exceptions
you have to permit
On Wed, Feb 26, 2014 at 04:24:54PM -0500, Steve Dainard wrote:
Would it not be possible for root to disable selinux enforcement?
Normally yes, if you're root, you can do all kinds of stuff including
appending 'selinux=0' to the kernel command line. Maybe there are better
SELinux experts on the
On Wed, Feb 26, 2014 at 04:24:54PM -0500, Steve Dainard wrote:
Would it not be possible for root to disable selinux enforcement?
It should also be possible to copy private keys out of ~user/.ssh and login to
other machines as user, assuming no password on the ssh key pair.
It's probably
On 02/27/2014 04:03 PM, Nordgren, Bryce L -FS wrote:
On Wed, Feb 26, 2014 at 04:24:54PM -0500, Steve Dainard wrote:
Would it not be possible for root to disable selinux enforcement?
It should also be possible to copy private keys out of ~user/.ssh and login to other
machines as user, assuming
But I
would argue that in this case root can just add some other module to the
pam stack that would dump passwords for any user who uses pam stack
regardless whether SSSD is in the picture or not so it is not SSSD problem and
I do not think it can be generally solved with the software. It
On Thu, Feb 27, 2014 at 09:03:35PM +, Nordgren, Bryce L -FS wrote:
On Wed, Feb 26, 2014 at 04:24:54PM -0500, Steve Dainard wrote:
Would it not be possible for root to disable selinux enforcement?
It should also be possible to copy private keys out of ~user/.ssh and login
to other
On Thu, Feb 27, 2014 at 10:36:01PM +, Nordgren, Bryce L -FS wrote:
But I
would argue that in this case root can just add some other module to the
pam stack that would dump passwords for any user who uses pam stack
regardless whether SSSD is in the picture or not so it is not SSSD
Would it not be possible for root to disable selinux enforcement? A user
could maybe even use a livecd if root couldn't be gained directly.
I'm looking at joining workstations to an idm realm, but some users will
need sudo permissions on their machines.
Is there any documentation on best
Hi,
When being root on an ipa-client, I can su to any IPA user. This is
somewhat unexptected behaviour in comparison to Windows. If I am local
administrator in a windows AD member server, I cannot become a domain user.
I need to be domain administrator for that.
Is it possible to have this
On Fri, 29 Nov 2013, Fred van Zwieten wrote:
Hi,
When being root on an ipa-client, I can su to any IPA user. This is
somewhat unexptected behaviour in comparison to Windows. If I am local
administrator in a windows AD member server, I cannot become a domain user.
I need to be domain
Jakub,
Yes, I could do this. But then the local root account cannot su to local
users (without password). But that is actually a normal use-case. I just
think local root should not be allowed to transition to a domain user, by
default.
Fred
On Fri, Nov 29, 2013 at 2:48 PM, Jakub Hrozek
On Fri, Nov 29, 2013 at 03:08:44PM +0100, Fred van Zwieten wrote:
Jakub,
Yes, I could do this. But then the local root account cannot su to local
users (without password). But that is actually a normal use-case. I just
think local root should not be allowed to transition to a domain user, by
On 11/29/2013 03:17 PM, Jakub Hrozek wrote:
On Fri, Nov 29, 2013 at 03:08:44PM +0100, Fred van Zwieten wrote:
Jakub,
Yes, I could do this. But then the local root account cannot su to local
users (without password). But that is actually a normal use-case. I just
think local root should not
18 matches
Mail list logo