Disabling local access for normal users

January 8, 2010

If you want to disable only local login for normal users you can use the file /etc/security/access.conf for this purpose however it doesn’t work by default even if you configure this file properly. For example, if you want to allow root logins locally but not any other user, edit access.conf file such that;

-:ALL EXCEPT root:ALL

Literally the above line means ” Disable (-) all users’  (ALL) login access except (EXCEPT) root user (root) and allow root user to login via all terminals.

We haven’t finished yet as we must introduce this file into pam configuration. The necessary pam module is “pam_access” my new /etc/pam.d/login file is as follows:

#%PAM-1.0
auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so
auth       include      system-auth
account    required     pam_nologin.so
account    required     pam_access.so
account    include      system-auth
password   include      system-auth
# pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
session    include      system-auth
session    required     pam_loginuid.so
session    optional     pam_console.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session    required     pam_selinux.so open
session    optional     pam_keyinit.so force revoke

By the default, the red line isn’t in this file. Once you add it, you will see that access restrictions are applied.

Disabling su for normal users

January 8, 2010

When I install Gentoo, as far as I remember, by default normal users aren’t allowed to use “su” . If you want to let any user to use “su” then you have to add them into the “wheel” user group. In redhat, you can uncomment one line, and it works like a charm.

Edit the file /etc/pam.d/su :

#%PAM-1.0
auth            sufficient      pam_rootok.so
# Uncomment the following line to implicitly trust users in the “wheel” group.
#auth           sufficient      pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the “wheel” group.
#auth            required        pam_wheel.so use_uid
auth            include         system-auth
account         sufficient      pam_succeed_if.so uid = 0 use_uid quiet
account         include         system-auth
password        include         system-auth
session         include         system-auth
session         optional        pam_xauth.so

If you uncomment the red line;

#%PAM-1.0
auth            sufficient      pam_rootok.so
# Uncomment the following line to implicitly trust users in the “wheel” group.
#auth           sufficient      pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the “wheel” group.
auth            required        pam_wheel.so use_uid
auth            include         system-auth
account         sufficient      pam_succeed_if.so uid = 0 use_uid quiet
account         include         system-auth
password        include         system-auth
session         include         system-auth
session         optional        pam_xauth.so

Then users have to be in wheel group in order to gain access to root privileges. Once you add your normal user into wheel user e.g

usermod -G wheel testuser

this test users can switch into root user.

Displaying certificates with openssl

January 8, 2010

Sometimes you need to view certificates with a simple utility rather then using a browser or MUA. Here is how you can do it with openssl. For instance you would like to display the certificate of https://192.168.200.1  , lets do it;

DISPLAYING A REMOTE CERTIFICATE

# openssl s_client -connect 192.168.200.1:443
CONNECTED(00000003)
depth=0 /C=–/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=localhost.localdomain/emailAddress=root@localhost.localdomain
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=–/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=localhost.localdomain/emailAddress=root@localhost.localdomain
verify error:num=9:certificate is not yet valid
notBefore=Dec  8 18:44:11 2009 GMT
verify return:1
depth=0 /C=–/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=localhost.localdomain/emailAddress=root@localhost.localdomain
notBefore=Dec  8 18:44:11 2009 GMT
verify return:1

Certificate chain
0 s:/C=–/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=localhost.localdomain/emailAddress=root@localhost.localdomain
i:/C=–/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=localhost.localdomain/emailAddress=root@localhost.localdomain

Server certificate
—–BEGIN CERTIFICATE—–
MIIEDjCCA3egAwIBAgICRrUwDQYJKoZIhvcNAQEFBQAwgbsxCzAJBgNVBAYTAi0t
MRIwEAYDVQQIEwlTb21lU3RhdGUxETAPBgNVBAcTCFNvbWVDaXR5MRkwFwYDVQQK
ExBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLExZTb21lT3JnYW5pemF0aW9uYWxV
bml0MR4wHAYDVQQDExVsb2NhbGhvc3QubG9jYWxkb21haW4xKTAnBgkqhkiG9w0B
CQEWGnJvb3RAbG9jYWxob3N0LmxvY2FsZG9tYWluMB4XDTA5MTIwODE4NDQxMVoX
DTEwMTIwODE4NDQxMVowgbsxCzAJBgNVBAYTAi0tMRIwEAYDVQQIEwlTb21lU3Rh
dGUxETAPBgNVBAcTCFNvbWVDaXR5MRkwFwYDVQQKExBTb21lT3JnYW5pemF0aW9u
MR8wHQYDVQQLExZTb21lT3JnYW5pemF0aW9uYWxVbml0MR4wHAYDVQQDExVsb2Nh
bGhvc3QubG9jYWxkb21haW4xKTAnBgkqhkiG9w0BCQEWGnJvb3RAbG9jYWxob3N0
LmxvY2FsZG9tYWluMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCqP30TzVK+
kO/V8g7PLP4gDDBAJAoQheb/I8Fg4pMiWUKnBE1hqftCOWcd1KTyNWgXPNB+xspE
5G+3Lk5enccuzr/r0YrjJHWYNzKge4tau1sLSqpBWlFGyQmBlP1JBG2vBQMy9nu6
t/RtJMii6yDm9H6xj10h98wXut8D6mOyQwIDAQABo4IBHTCCARkwHQYDVR0OBBYE
FPbm+ZFfjHJF3HtyQDzO31YbNVaNMIHpBgNVHSMEgeEwgd6AFPbm+ZFfjHJF3Hty
QDzO31YbNVaNoYHBpIG+MIG7MQswCQYDVQQGEwItLTESMBAGA1UECBMJU29tZVN0
YXRlMREwDwYDVQQHEwhTb21lQ2l0eTEZMBcGA1UEChMQU29tZU9yZ2FuaXphdGlv
bjEfMB0GA1UECxMWU29tZU9yZ2FuaXphdGlvbmFsVW5pdDEeMBwGA1UEAxMVbG9j
YWxob3N0LmxvY2FsZG9tYWluMSkwJwYJKoZIhvcNAQkBFhpyb290QGxvY2FsaG9z
dC5sb2NhbGRvbWFpboICRrUwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOB
gQBNUijzKybFB2a/vDpetJ9AEyyLFwlqnF2QIY577pYo6WBR/w6XsEo7oN2PHRKB
z77OfW9Wt15tTMqm3gZMHVY7wmnWA0uVbnbnAL90Ht6pdRvqYy7CyejaKJQKPBhI
ZjGKWJlPzgf5gro4nSPwoG+qFnmJYotoFfGP9+5gF1HEmA==
—–END CERTIFICATE—–
subject=/C=–/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=localhost.localdomain/emailAddress=root@localhost.localdomain
issuer=/C=–/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=localhost.localdomain/emailAddress=root@localhost.localdomain

No client certificate CA names sent

SSL handshake has read 1606 bytes and written 316 bytes

New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1
Cipher    : DHE-RSA-AES256-SHA
Session-ID: 1B7226891FBA809022C13F2ECC68E602895ADBA11F8FCB93630BA7DC643B1781
Session-ID-ctx:
Master-Key: 46F7E40AE4688DFBDCDBAE5B261078323A227C21988F78B568A8F15C660CD2C9C4A8FF517B71A460B1C2CFF8F51FAF7F
Key-Arg   : None
Krb5 Principal: None
Start Time: 1136128014
Timeout   : 300 (sec)
Verify return code: 9 (certificate is not yet valid)

DISPLAYING A LOCAL CERTIFICATE (FILE)

If you issue the following command for the certificate file (server.crt) locally saved, you will see the certificate details

#openssl x509 -in server.crt -text

Permanent routes in Redhat

January 8, 2010

I was trying to find out how I can add a permanent route into Redhat so that after the reboot routes should persist. I have found the way but I must say that I really didn’t like it:( I liked the way Gentoo does it or Slackware but Redhat’s way seems to be too simplistic but it causes more work. Here is how it works;

It is sufficient to add your routes into the file /etc/sysconfig/network-scripts/route-ethX. Replace X with your interface number. For example;

In /etc/sysconfig/network-scripts/route-eth0, I have added the following routes to make them permanent.

ADDRESS0=10.0.0.222
NETMASK0=255.255.255.255
GATEWAY0=192.168.200.81

ADDRESS1=10.0.0.223
NETMASK1=255.255.255.255
GATEWAY1=192.168.200.79

Each time you need another route, you must just increment each variable by one, then route will stay in routing table after the reboot.

You may be asking why we don’t/can’t add the route into rc.local or somewhere else. IMHO, it is best practice to use the tools provided by the distribution so that if another engineer needs to take a look into the system, he will know for sure where to look.

SELinux and SAMBA

January 7, 2010

In this article we will configure samba based on a case in which SELinux is enabled again . The case is:

“Setup samba in such a way that only users mert and yigit will be able to access the folder /samba_share in the server”

1) First create the folder and set the permissions for these users and adjust selinux settings.

[root@rh54-2 /]# mkdir /samba_share
[root@rh54-2 /]# setfacl -m u:mert:rwx /samba_share/
[root@rh54-2 /]# setfacl -m u:yigit:rwx /samba_share/
[root@rh54-2 /]# getfacl /samba_share/
getfacl: Removing leading ‘/’ from absolute path names
# file: samba_share
# owner: root
# group: root
user::rwx
user:yigit:rwx
user:mert:rwx
group::r-x
mask::rwx
other::r-x

From the getfacl output we can see that root,mert and yigit users have full access on this folder.

Now put this new share under the security context type of samba which is : samba_share_t

[root@rh54-2 ~]# chcon -R -t samba_share_t /samba_share/
[root@rh54-2 ~]# semanage fcontext -a -t samba_share_t “/samba_share(/.*)?”

As it can be seen we have also added the folder into the policy so that if relabeling is performed, this folder won’t be affected.

2) Setup SAMBA config to allow access for these users

[sambatest]
comment = share for mert and yigit
path = /samba_share
writable = yes
valid users = yigit mert

and reload samba

[root@rh54-2 ~]# /etc/init.d/smb reload
Reloading smb.conf file: [  OK  ]

Note: As we have used “valid users” option for users, no other users are allowed even to display/login into this share. If we had written
writable = no” and “write list = yigit mert” , then other users would have also gained access into this share.

Continue Reading »

SELinux and BIND

January 5, 2010

When SELinux and BIND are together, there is not much to say as there are only two booleans that you can toggle as you can see below;

[root@rh54-2 named]# getsebool -a | grep named
named_disable_trans –> off
named_write_master_zones –> off

Continue Reading »

SELinux and Apache

January 5, 2010

SELinux (Security Enhanced Linux) is something that some of us may be afraid of because once it is enabled network services start to behave abnormally. However once it is configured properly you can restrict processes and enforce their access to files and directories as you wish. In this article we will speak briefly about integration of SELinux with Apache.

SELinux modes

There three modes of SELinux

  • Enforcing : You can restrict processes in this mode
  • Permissive : You can see what might happen in the logs if the mode was Enforcing instead of Permissive.
  • Disabled : Inactive state

You can query the runtime mode with “getenforce”:

[root@rh54-3 ~]# getenforce
Enforcing

or you can set the SELinux mode with “setenforce”:

[root@rh54-3 ~]# setenforce 0
[root@rh54-3 ~]# getenforce
Permissive

Note: If you want to set the selinux mode to enforcing, you must reboot the server to relabel the filesystem. To have your changes to be persistent between reboots, set the SELinux mode in /etc/sysconfig/selinux file.

Redhat uses targeted policy by default which isn’t very strict and mainly service focused.

Continue Reading »

LDAP authentication howto

January 3, 2010

In our previous article we have configured our systems to authenticate from an NIS server. Now we are using LDAP which is more effective and easy to manage.  Software installation isn’t within the scope of this documentation but pure configuration. Our tests systems are Redhat 5.4 but you can use this in other redhat based systems. Lets start;

Here are the details about our setup once:

LDAP Server: rh54srv1.iptables.gen.tr
Linux client: rh54-2.iptables.gen.tr

[LDAP configuration]

Adjust the following lines in your /etc/openldap/slapd.conf

database        bdb
suffix          “dc=iptables,dc=gen,dc=tr”
rootdn          “cn=Manager,dc=iptables,dc=gen,dc=tr”
rootpw          iptables123

Start LDAP server:

[root@rh54srv1]# /etc/init.d/ldap start

Send a sample query to our fresh LDAP server to test the queries. Be careful command should be in single line and shouldn’t be wrapped, if so, use backslash.

[root@rh54srv1 /]# ldapsearch -h rh54srv1.iptables.gen.tr -x -D “cn=Manager,dc=iptables,dc=gen,dc=tr” -b \  “dc=iptables,dc=gen,dc=tr”  -w iptables123
# extended LDIF
#
# LDAPv3
# base <dc=iptables,dc=gen,dc=tr> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object

# numResponses: 1

This is a good answer:) though we haven’t received any records as we don’t have any.

Now we will migrate our current password and group files into LDAP. Get the following scripts for this purpose:

Continue Reading »

NIS & Autofs configuration

January 3, 2010

This article is about to configure NIS server and NIS client in a redhat base distribution.  I know that NIS isn’t the preferred method of authentication anymore but I wanted to add this short NIS document along with autofs usage so that when any user logs in, their homedirectories at the remote NFS server will be mounted automatically.

Lets start:

Sample NIS domain: penguen.com
NIS Server: rh54srv1.penguen.com
NIS Server IP:  192.168.200.1
NIS Client IP: 192.168.200.81

**Don’t forget that this hostname to IP mapping must exist in /etc/hosts file.

[SERVER SIDE CONFIGURATION]

Install the packages required for NIS server

ypserv
ypbind
portmap
yp-tools

Add the following line  into cat /etc/sysconfig/network

NISDOMAIN=”penguen.com”

Start the following daemons

service portmap start
service ypserv start
service yppasswdd start

Continue Reading »

Software Raid

January 3, 2010

Software raid configuration is quite easy and within a few minutes you can start building your array. Depending on the size of the array, build time may vary. Here is a quick instruction about how you can use mdadm utility to create a raid 1 array.

We have two partitions of the size 512MB in two different disks:

First Partition: /dev/sdb2
Second Partition: /dev/sdc1
Partition Types: fd (Linux raid auto detect)

As we are creating a raid paritition, using fdisk set both partition types to the code “fd” . Your output from fdisk will be something like below;

[root@rh54-2 ~]# fdisk /dev/sdb -l

Disk /dev/sdb: 1073 MB, 1073741824 bytes
255 heads, 63 sectors/track, 130 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1          63      506016   83  Linux
/dev/sdb2              64         130      538177+  fd  Linux raid autodetect

Continue Reading »

 
Powered by Wordpress and MySQL. Theme by Shlomi Noach, openark.org