ksu - Online na nuvem

PROGRAMA:

NOME

ksu - superusuário Kerberizado

SINOPSE

ksu [ usuário_alvo ] [ -n nome_principal_alvo ] [ -c nome_cache_fonte ] [ -k ] [ -D ] [
-r Tempo ] [ -pf ] [ -l lifetime deals ] [ -z | Z ] [ -q ] [ -e comando [args ...]] [ -a [
args ...]]

REQUISITOS

Deve ter o Kerberos versão 5 instalado para compilar o ksu. Deve ter um Kerberos versão 5
servidor em execução para usar o ksu.

DESCRIÇÃO

ksu é uma versão Kerberizada do programa su que tem duas missões: uma é com segurança
mude o ID do usuário real e efetivo para o do usuário-alvo, e o outro é para
criar um novo contexto de segurança.

OBSERVAÇÃO:
Para fins de clareza, todas as referências e atributos do usuário que invoca o
o programa iniciará com "fonte" (por exemplo, "usuário fonte", "cache fonte", etc.).

Da mesma forma, todas as referências e atributos da conta de destino começarão com
"alvo".

AUTENTICAÇÃO

Para cumprir a primeira missão, o ksu opera em duas fases: autenticação e
autorização. Resolver o nome principal de destino é a primeira etapa da autenticação.
O usuário pode especificar seu nome principal com o -n opção (por exemplo, -n
[email protected]) ou um nome principal padrão será atribuído usando uma heurística descrita
na seção OPÇÕES (ver -n opção). O nome do usuário de destino deve ser o primeiro argumento
para ksu; se não for especificado, root é o padrão. Se . for especificado, então o usuário alvo irá
ser o usuário de origem (por exemplo, ksu .) Se o usuário de origem for root ou o usuário de destino for o
usuário de origem, nenhuma autenticação ou autorização ocorre. Caso contrário, ksu procura por um
tíquete Kerberos apropriado no cache de origem.

O tíquete pode ser para o servidor final ou um tíquete de concessão de tíquete (TGT) para o
reino do principal alvo. Se o tíquete para o servidor final já estiver no cache, é
descriptografado e verificado. Se não estiver no cache, mas o TGT estiver, o TGT é usado para
obter o tíquete para o servidor final. O tíquete do servidor final é então verificado. Se nenhum
o tíquete está no cache, mas o ksu é compilado com o GET_TGT_VIA_PASSWD definir, o usuário
será solicitada uma senha Kerberos que será usada para obter um TGT. Se o
usuário está logado remotamente e não tem um canal seguro, a senha pode ser
expor. Se nenhum dos tíquetes estiver no cache e GET_TGT_VIA_PASSWD não está definido,
a autenticação falha.

AUTORIZAÇÃO

Esta seção descreve a autorização do usuário de origem quando ksu é invocado sem o -e
opção. Para uma descrição do -e opção, consulte a seção OPÇÕES.

Após a autenticação bem-sucedida, o ksu verifica se o principal alvo está autorizado a
acessar a conta de destino. No diretório inicial do usuário de destino, ksu tenta acessar
dois arquivos de autorização: .k5login(5). e .k5users. No arquivo .k5login, cada linha
contém o nome de um principal autorizado a acessar a conta.

Por exemplo:

[email protected]
jqpublic /[email protected]
jqpublic /[email protected]

O formato de .k5users é o mesmo, exceto que o nome principal pode ser seguido por uma lista de
comandos que o principal está autorizado a executar (consulte o -e opção nas OPÇÕES
seção para detalhes).

Assim, se o nome principal de destino for encontrado no arquivo .k5login, o usuário de origem é
autorizado a acessar a conta de destino. Caso contrário, o ksu procura no arquivo .k5users. Se
o nome principal de destino é encontrado sem nenhum comando posterior ou seguido apenas por *
então, o usuário de origem está autorizado. Se .k5login ou .k5users existirem, mas um
a entrada apropriada para o principal de destino não existe, então o acesso é negado. Se
nenhum arquivo existe, então o principal terá acesso à conta de acordo com
as regras de mapeamento aname-> lname. Caso contrário, a autorização falha.

EXECUÇÃO OF A TARGET SHELL

Após a autenticação e autorização bem-sucedidas, o ksu procede de maneira semelhante ao su.
O ambiente não foi modificado, com exceção das variáveis ​​USER, HOME e SHELL. Se
o usuário de destino não é root, USER é definido como o nome de usuário de destino. Caso contrário, USUÁRIO
permanece inalterado. Tanto HOME quanto SHELL são configurados com os valores padrão do login de destino. No
além disso, a variável de ambiente KRB5CCNAME é definido com o nome do cache de destino.
O ID do usuário real e efetivo é alterado para aquele do usuário alvo. O usuário alvo
o shell é então chamado (o nome do shell é especificado no arquivo de senha). Sobre
término do shell, ksu exclui o cache de destino (a menos que ksu seja invocado com o -k
opção). Isso é implementado primeiro fazendo um fork e, em seguida, um exec, em vez de apenas
exec, feito por su.

CRIANDO A NOVAS SEGURANÇA CONTEXTO

ksu pode ser usado para criar um novo contexto de segurança para o programa alvo (seja o alvo
shell ou comando especificado por meio do -e opção). O programa de destino herda um conjunto de
credenciais do usuário de origem. Por padrão, este conjunto inclui todas as credenciais em
o cache de origem mais quaisquer credenciais adicionais obtidas durante a autenticação. o
o usuário de origem pode limitar as credenciais neste conjunto usando -z or -Z opção. -z
restringe a cópia de tíquetes do cache de origem para o cache de destino apenas para o
tickets em que client == o nome do principal alvo. o -Z opção fornece o usuário-alvo
com um novo cache de destino (sem creds no cache). Observe que, por razões de segurança, quando
o usuário de origem é root e o usuário de destino não é root, -z opção é o modo padrão de
operação.

Embora nenhuma autenticação ocorra se o usuário de origem for root ou for o mesmo que o
usuário-alvo, tíquetes adicionais ainda podem ser obtidos para o cache de destino. Se -n is
especificado e nenhuma credencial pode ser copiada para o cache de destino, o usuário de origem é
solicitada uma senha Kerberos (a menos que -Z especificado ou GET_TGT_VIA_PASSWD é indefinido).
Se for bem-sucedido, um TGT é obtido do servidor Kerberos e armazenado no cache de destino.
Caso contrário, se uma senha não for fornecida (usuário pressiona retornar), o ksu continua no modo normal
de operação (o cache de destino não conterá o TGT desejado). Se a senha errada
é digitado, ksu falha.

OBSERVAÇÃO:
Durante a autenticação, apenas os tíquetes que poderiam ser obtidos sem fornecer um
as senhas são armazenadas em cache no cache de origem.

OPÇÕES

-n nome_principal_alvo
Especifique um nome principal de destino Kerberos. Usado em autenticação e autorização
fases de ksu.

Se ksu for invocado sem -n, um nome principal padrão é atribuído por meio do
seguinte heurística:

· Caso 1: o usuário de origem não é root.

Se o usuário de destino for o usuário de origem, o nome principal padrão será definido como
principal padrão do cache de origem. Se o cache não existir, o
nome principal padrão é definido como target_user @ local_realm. Se a fonte e
os usuários-alvo são diferentes e nenhum ~ target_user / .k5users nem
~ target_user / .k5login existir, então o nome principal padrão é
target_user_login_name @ local_realm. Caso contrário, começando com o primeiro principal
listado abaixo, ksu verifica se o principal está autorizado a acessar o alvo
conta e se há um tíquete legítimo para esse principal na fonte
cache. Se ambas as condições forem atendidas, o principal se torna o alvo padrão
principal, caso contrário, vá para o próximo principal.

uma. principal padrão do cache de origem

b. target_user @ local_realm

c. source_user @ local_realm

Se ac falhar, tente qualquer principal para o qual haja um tíquete no cache de origem
e que está autorizado a acessar a conta de destino. Se isso falhar, selecione o
primeiro principal autorizado a acessar a conta de destino acima
Lista. Se nenhum estiver autorizado e ksu estiver configurado com PRINC_LOOK_AHEAD virou-se
ativado, selecione o principal padrão da seguinte forma:

Para cada candidato na lista acima, selecione um diretor autorizado que tenha o
mesmo nome de domínio e primeira parte do nome principal igual ao prefixo do
candidato. Por exemplo, se o candidato a) é [email protected] e
jqpublic /[email protected] está autorizado a acessar a conta de destino, então o
o principal padrão é definido como jqpublic /[email protected].

· Caso 2: o usuário de origem é root.

Se o usuário de destino não for root, o nome principal padrão é
target_user @ local_realm. Caso contrário, se o cache de origem existir, o principal padrão
name é definido como o principal padrão do cache de origem. Se o cache de origem
não existe, o nome principal padrão é definido como root \ @local_realm.

-c nome_cache_fonte
Especifique o nome do cache de origem (por exemplo, -c ARQUIVO: / tmp / my_cache). Se -c opção não é usada então
o nome é obtido de KRB5CCNAME variável de ambiente. Se KRB5CCNAME não é
definido, o nome do cache de origem é definido como krb5cc_ uid>. O nome do cache de destino é
definido automaticamente para krb5cc_ uid>. (gen_sym ()), onde gen_sym gera um novo
número de forma que o cache resultante ainda não exista. Por exemplo:

krb5cc_1984.2

-k Não exclua o cache de destino após o término do shell de destino ou um comando
(-e comando). Sem -k, ksu exclui o cache de destino.

-D Ative o modo de depuração.

-z Restringir a cópia de tíquetes do cache de origem para o cache de destino apenas para o
tickets em que client == o nome do principal alvo. Use o -n opção se você quiser
os tickets para outro que não seja o principal padrão. Observe que o -z opção
mutuamente exclusivo com o -Z opção.

-Z Não copie nenhum tíquete do cache de origem para o cache de destino. Basta criar um
novo cache de destino, onde o nome principal padrão do cache é inicializado para
o nome principal de destino. Observe que o -Z opção é mutuamente exclusiva com o
-z opção.

-q Suprime a impressão de mensagens de status.

Opções de concessão de tíquetes:

-l lifetime deals -r tempo -pf
As opções de concessão de tíquete só se aplicam ao caso em que não há
tíquetes apropriados no cache para autenticar o usuário de origem. Neste caso, se
ksu está configurado para solicitar aos usuários uma senha Kerberos (GET_TGT_VIA_PASSWD is
definido), as opções de concessão de tíquete especificadas serão usadas quando
obter um tíquete de concessão de tíquete do servidor Kerberos.

-l lifetime deals
(duração string.) Especifica o tempo de vida a ser solicitado para o tíquete; se este
opção não for especificada, o tempo de vida do tíquete padrão (12 horas) é usado em seu lugar.

-r tempo
(duração string.) Especifica que o renovável opção deve ser solicitada para o
tíquete e especifica a vida útil total desejada do tíquete.

-p especifica que o próximo opção deve ser solicitada para o bilhete.

-f opção especifica que o transmitível opção deve ser solicitada para o bilhete.

-e comando [args ...]
ksu procede exatamente da mesma forma como se fosse invocado sem o -e opção, exceto
em vez de executar o shell de destino, o ksu executa o comando especificado. Exemplo
de uso:

ksu bob -e ls -lag

O algoritmo de autorização para -e é como se segue:

Se o usuário de origem é root ou usuário de origem == usuário de destino, nenhuma autorização leva
coloque e o comando é executado. Se o id do usuário de origem! = 0, e
~ target_user / .k5users arquivo não existe, a autorização falha. De outra forma,
~ target_user / .k5users arquivo deve ter uma entrada apropriada para o principal alvo para
seja autorizado.

O formato de arquivo .k5users:

Uma única entrada principal em cada linha que pode ser seguida por uma lista de comandos
que o principal está autorizado a executar. Um nome principal seguido por um *
significa que o usuário está autorizado a executar qualquer comando. Assim, no seguinte
exemplo:

[email protected] ls mail / local / kerberos / klist
jqpublic /[email protected] *
jqpublic /[email protected]

[email protected] só está autorizado a executar ls, enviar e lista de cliques comandos.
jqpublic /[email protected] está autorizado a executar qualquer comando.
jqpublic /[email protected] não está autorizado a executar nenhum comando. Observe que
jqpublic /[email protected] está autorizado a executar o shell alvo (ksu regular,
sem o -e opção) mas [email protected] não é.

Os comandos listados após o nome principal devem ser nomes de caminhos completos ou
apenas o nome do programa. No segundo caso, CMD_PATH especificando a localização de
os programas autorizados devem ser definidos no momento da compilação do ksu. Qual comando
é executado?

Se o usuário de origem é root ou o usuário de destino é o usuário de origem ou o usuário é
autorizado a executar qualquer comando (* entrada), então o comando pode ser um completo ou um
caminho relativo que leva ao programa de destino. Caso contrário, o usuário deve especificar
um caminho completo ou apenas o nome do programa.

-a args
Especifique os argumentos a serem passados ​​para o shell de destino. Observe que todos os sinalizadores e
parâmetros após -a serão passados ​​para o shell, portanto, todas as opções destinadas a
ksu deve preceder -a.

O -a opção pode ser usada para simular o -e opção se usada da seguinte forma:

-a -c [comando [argumentos]].

-c é interpretado pelo c-shell para executar o comando.

INSTALAÇÃO INSTRUÇÕES

ksu pode ser compilado com as seguintes quatro opções:

GET_TGT_VIA_PASSWD
Caso nenhum tíquete apropriado seja encontrado no cache de origem, o usuário será
solicitada uma senha Kerberos. A senha é então usada para obter um tíquete
concessão de tíquete do servidor Kerberos. O perigo de configurar ksu com este
macro é se o usuário de origem estiver conectado remotamente e não tiver um
canal, a senha pode ser exposta.

PRINC_LOOK_AHEAD
Durante a resolução do nome principal padrão, PRINC_LOOK_AHEAD habilita ksu
para encontrar nomes principais no arquivo .k5users conforme descrito na seção OPÇÕES
(Vejo -n opção).

CMD_PATH
Especifica uma lista de diretórios contendo programas para os quais os usuários estão autorizados
executar (via arquivo .k5users).

HAVE_GETUSERSSHELL
Se o usuário de origem não for root, ksu insiste que o shell do usuário de destino seja
invocado é um "escudo legal". getusershell(3). é chamado para obter os nomes de
"cascas legais". Observe que o shell do usuário de destino é obtido a partir do passwd
arquivo.

Configuração de amostra:

KSU_OPTS = -DGET_TGT_VIA_PASSWD -DPRINC_LOOK_AHEAD -DCMD_PATH = '"/ bin / usr / ucb / local / bin "

ksu deve pertencer ao root e ter o bit de id do usuário definido ativado.

O ksu tenta obter um tíquete para o servidor final da mesma forma que o telnet e o rlogin Kerberizados.
Assim, deve haver uma entrada para o servidor no banco de dados Kerberos (por exemplo,
hospedeiro/[email protected]) O arquivo keytab deve estar em um local apropriado.

LADO EFEITOS

ksu exclui todos os tíquetes expirados do cache de origem.

AUTOR OF KSU

GENNADY (ARI) MEDVINSKY

Use ksu online usando serviços onworks.net